Synology VDSM : Déplacement de Docker avec l’IA et redimensionnement d’un disque virtuel (2026)

Un NAS virtuel fait partie de ces fonctionnalités qu'on installe une fois, qu'on teste brièvement, puis qu'on oublie. C'est dommage, car Synology VDSM (Virtual DSM exécuté dans Virtual Machine Manager) résout discrètement deux des problèmes les plus agaçants de l'auto-hébergement à petite échelle. Premièrement, déplacer une pile Docker d'une machine à l'autre prend généralement une soirée entière à cause de tâches fastidieuses. Deuxièmement, lorsqu'un disque virtuel est saturé, la plupart des utilisateurs pensent devoir tout reconstruire. Avec VDSM, ce n'est pas le cas. Ce guide décrit une migration réelle que nous avons effectuée en une trentaine de minutes : un outil de suivi des problèmes Redmine interne, avec cinq plugins, a été extrait d'une machine virtuelle VDSM et transféré vers une autre, avec un assistant IA pilotant l'interface. En cours de route, la destination a manqué d'espace disque ; nous avons donc augmenté son disque virtuel de 10 Go à 20 Go et poursuivi l'opération. La suite décrit le déroulement exact des opérations, y compris le piège qui aurait pu détruire l'application sans le moindre bruit.

Point SynoPower Club :J'ai vu beaucoup de personnes renoncer à la virtualisation sur un NAS, la considérant comme une solution de laboratoire et non pour un usage professionnel. La migration décrite dans cet article était un véritable projet : un système de tickets utilisé quotidiennement par trois collègues. Ce qui m'a surpris, ce n'est pas l'IA, mais la simplicité d'utilisation de VDSM. Pas d'hyperviseur à licencier, pas de serveur de gestion dédié, pas de jonglage entre formats incompatibles. La machine virtuelle a manqué d'espace disque en cours de migration ; j'ai résolu le problème en saisissant une valeur plus élevée dans un champ texte, sans interruption de service. L'opération a duré trente-cinq minutes et la seule interruption perceptible a été de 90 secondes sur un site web sans rapport avec le projet. Si vous possédez déjà un Synology avec de la mémoire disponible, l'installation d'un seul paquet suffit.

Qu'est-ce que le VDSM Synology ?

VDSM est l'équivalent de Virtual DSM pour Synology : une copie complète de DiskStation Manager exécutée comme système d'exploitation invité au sein de Virtual Machine Manager sur un NAS physique. Il se comporte comme un NAS distinct : sa propre adresse IP, son propre identifiant DSM, ses propres paquets et son propre gestionnaire de conteneurs. Du point de vue du réseau, il s'agit simplement d'un autre Synology sur le réseau local. Du point de vue matériel, c'est un processus supplémentaire sur un appareil que vous avez déjà acheté.

L'avantage pratique réside dans l'isolation. Si chaque service est exécuté directement sur l'hôte, un conteneur défaillant peut paralyser le serveur de fichiers dont dépend tout le bureau. La répartition des charges de travail entre les machines virtuelles VDSM leur attribue une limite de mémoire, une allocation de processeur et un disque dédiés, et permet de redémarrer l'une d'entre elles indépendamment des autres.

Chaque NAS compatible Virtual Machine Manager inclut une licence VDSM gratuite. L'exécution d'une deuxième machine virtuelle et des suivantes nécessite une licence VDSM. Licence Virtual DSM payante Chaque instance gratuite suffit pour suivre l'intégralité de cet article, et c'est pourquoi tant de personnes possèdent déjà cette fonctionnalité sans jamais l'avoir activée. Si vous devez ajouter, associer ou dissocier une licence ultérieurement, nous proposons un guide pas à pas sur [lien manquant]. gestion des licences VDSM.

VDSM et Virtual DSM désignent la même chose. La documentation officielle de Synology utilise la forme longue, tandis que la plupart des utilisateurs préfèrent la forme courte. Cette abréviation est également utilisée pour un autre composant du projet de virtualisation oVirt ; par conséquent, sur un NAS Synology, elle correspond toujours à Virtual DSM.

Une licence payante fonctionne différemment de ce à quoi la plupart des utilisateurs s'attendent. Chaque licence ajoute une machine virtuelle et inclut trois ans de mises à jour logicielles Virtual DSM. La machine virtuelle n'expire jamais. Après ces trois ans, elle continue de fonctionner sans mises à jour. L'activation d'une nouvelle clé lance trois nouvelles années de mises à jour. Une clé ne peut être active que sur un seul NAS Synology à la fois, et le NAS doit être en ligne lors de son ajout.

Les exigences pour un invité VDSM sont modestes, et Synology les répertorie dans sa documentation. Spécifications Virtual Machine Manager:

• Le disque virtuel doit se trouver sur un volume Btrfs. Virtual Machine Manager ne stocke pas les machines virtuelles invitées sur ext4.
• Le NAS lui-même nécessite plus de 2 Go de mémoire avant de pouvoir exécuter une machine virtuelle.
• Chaque machine virtuelle a besoin d'au moins 1 Go de mémoire, et les charges de travail importantes en nécessitent davantage.
• Le nombre d'invités qu'un modèle peut gérer confortablement dépend de son processeur et de sa mémoire installée.

Un système invité n'est pas identique à DSM sur un serveur physique. Trois éléments manquent, tous liés au matériel physique :

• La fonction de transfert USB n'est pas disponible ; par conséquent, un périphérique branché sur un port USB du NAS ne peut pas être mis à la disposition de la machine virtuelle invitée.
• Les pages « Périphériques externes » et « Matériel et alimentation » du Panneau de configuration sont absentes.
• Les clés Wi-Fi, les paramètres MTU et l'agrégation de liens (LACP) ne sont pas pris en charge au sein de la machine virtuelle. C'est l'hôte qui gère le réseau physique.

Cela n'affecte en rien les raisons habituelles d'utiliser un NAS. Les services de fichiers, Docker, un serveur de messagerie ou une copie de test d'un système de production fonctionnent tous comme sur un NAS distinct.

Synology VDSM ou un deuxième NAS physique : lequel vous faut-il ?

La comparaison honnête ne consiste pas à affirmer que le virtuel est meilleur. Il s'agit d'un compromis entre résilience et flexibilité. Un second serveur physique survit à la panne du premier ; une machine virtuelle VDSM, non. En revanche, une machine virtuelle vous offre la possibilité de créer, redimensionner, prendre des instantanés et déplacer un serveur entier en quelques minutes au lieu de plusieurs jours.

	Invité VDSM	Deuxième NAS physique
Coût d'ajout d'un	Gratuit pour le premier invité, ensuite licence.	Un NAS complet plus disques durs
Il est temps de provisionner	Minutes	Jours, une fois les frais de port comptabilisés
Redimensionner le processeur, la RAM ou le disque	Modifier un champ, redémarrer l'invité	Acheter du nouveau matériel
Survit à une panne matérielle de l'hôte	Non	Oui
Instantané et clone	Intégré au Virtual Machine Manager	Non applicable
Déplacer vers un autre NAS	Migrer ou répliquer l'invité	Déplacez-le physiquement
Idéal pour	Services d'isolation, de préproduction et de consolidation de petits serveurs	Cibles de sauvegarde et redondance réelle

Pour cette tâche, le choix était évident. Nous consolidions un système de suivi des problèmes peu utilisé, qui disposait d'une machine virtuelle VDSM dédiée, sur une machine virtuelle hébergeant déjà un site web avec de la capacité disponible. Aucune installation matérielle supplémentaire n'est requise. Dix minutes et un peu d'attention suffisent.

Ce dont vous avez besoin avant de commencer

Avant toute chose, attribuez à l'assistant ses propres identifiants plutôt que de lui communiquer les vôtres. Dans DSM, ouvrez le Panneau de configuration, accédez à Utilisateurs et groupes et cliquez sur Créer. Donnez-lui un nom facilement identifiable ; nous avons utilisé Claude avec la description Contrôle par IA — et laissez DSM générer un mot de passe aléatoire et robuste.

Sur l'écran suivant, cochez administrateurs. Ceci est indispensable : DSM n’autorise que les membres du groupe administrateurs à se connecter via SSH ; un compte n’appartenant pas à ce groupe ne peut donc pas accéder à l’interface de ligne de commande. Procédez de la même manière sur les deux machines virtuelles VDSM, puis assurez-vous que SSH est activé dans le Panneau de configuration, Terminal et SNMP.

Une fois le travail terminé, désactivez le compte. C'est précisément l'intérêt de créer un compte distinct. Modifiez l'utilisateur dans le Panneau de configuration et désactivez-le, ou supprimez-le purement et simplement ; l'accès est révoqué en un clic sans que vous ayez à toucher à vos propres identifiants, et toutes les actions de l'assistant restent attribuables à une connexion créée à cet effet. Laisser traîner un compte administrateur actif en permanence, simplement parce que c'était pratique à un moment donné, est la façon dont les petites structures accumulent des accès dont personne ne se souvient les avoir accordés.

Deux machines virtuelles VDSM, SSH activé sur les deux, et Container Manager installé sur la destination. Il est important de savoir que le binaire Docker ne se trouve pas dans le PATH par défaut de DSM. Les binaires des paquets résident dans leur répertoire d'installation ; par conséquent, chaque commande nécessite le chemin complet ou un alias shell.

Vérifiez la disponibilité d'espace à destination avant le départ, et non en cours de correspondance. Les commandes ci-dessous constituent l'intégralité de la vérification pré-vol et sont identiques pour tous les passagers VDSM.

Une dernière chose avant toute chose : Prenez une photo des deux invités dans Virtual Machine Manager. Les snapshots sont disponibles dans la version gratuite de Virtual Machine Manager, et pas seulement dans la version Pro. Il est possible d'en conserver jusqu'à 32 par machine virtuelle. Un snapshot VDSM capture l'intégralité de la machine ; ainsi, en cas d'erreur lors d'une importation ou si une commande produit un effet imprévu, vous restaurez la machine virtuelle au lieu de la recréer. Cette opération ne prend que quelques secondes et constitue la mesure de sécurité la plus économique de tout le processus. Il est conseillé de prendre un snapshot sur la source et un autre sur la destination, car la source sert de solution de repli.

# Docker n'est pas dans le PATH de DSM - utilisez le chemin complet D=/volume1/@appstore/ContainerManager/usr/bin/docker # Qu'est-ce qui est en cours d'exécution et à partir de quoi est-il construit ? sudo $D ps -a sudo $D images # Combien d'espace reste-t-il sur le volume de destination ? df -h /volume1 # Quelle est la quantité de mémoire libre réelle sur la machine virtuelle de destination ? free -m

Migration Docker VDSM en 4 étapes

Voici les quatre étapes que nous avons suivies ; elles fonctionnent pour toute pile de conteneurs à transférer entre machines virtuelles VDSM. L’ordre est important : le conteneur d’application est arrêté en premier afin d’éviter toute écriture dans la base de données pendant la sauvegarde, et le conteneur de base de données reste actif pour permettre une sauvegarde propre.

Pourquoi le fichier Compose ne correspond pas à l'intégralité du conteneur

Voici le piège, et il vaut à lui seul le détour. Le fichier Compose de notre stack Redmine déclarait deux montages de type bind : un pour les fichiers téléchargés, l’autre pour la base de données. À la lecture de ce fichier, on pourrait raisonnablement conclure que recréer la stack sur la nouvelle machine virtuelle se résumait à copier deux répertoires et à exécuter la commande `docker compose up`.

Non. Cinq plugins, les gems Ruby qu'ils utilisaient, la configuration de messagerie et plusieurs fichiers d'initialisation modifiés avaient tous été installés directement dans le conteneur en cours d'exécution au fil des ans. Rien n'était stocké dans un volume. Une simple commande nous a permis de constater la gravité de la situation.

# Combien de fichiers diffèrent entre le conteneur et l'image d'origine ? sudo $D diff Redmine | wc -l 6764 # Plugins résidant dans le conteneur, sans volume dédié sudo $D exec Redmine ls /usr/src/redmine/plugins

Utiliser une image officielle récente aurait créé un conteneur sans aucun de ces plugins, pointant vers une base de données contenant encore les 144 tables créées par leurs migrations. L'application n'aurait pas planté de manière flagrante. Elle aurait démarré, semblé fonctionner presque correctement, puis aurait dysfonctionné de manière extrêmement difficile à diagnostiquer. Utiliser le conteneur en cours d'exécution comme image contourne complètement le problème, au prix d'un transfert plus long. Sur un réseau local entre deux machines virtuelles VDSM, ce temps de transfert est d'environ une minute ; il est donc toujours préférable d'opter pour cette solution.

Comment une petite équipe utilise VDSM pour consolider ses serveurs

Le schéma de migration que suit cette équipe est celui dont la plupart des petites équipes finissent par avoir besoin. Au fil des années, on accumule des machines virtuelles dédiées à une seule tâche : une pour le wiki, une pour le système de suivi des tickets et une pour un tableau de bord de supervision (dont la structure est décrite dans notre [référence manquante]). Visite guidée du centre de données à domicileChacune de ces machines était surdimensionnée le jour de sa construction, et chacune fonctionne désormais au ralenti à une fraction de sa capacité initiale, tandis que le système hôte est surchargé et que tout semble légèrement lent.

La consolidation avec VDSM consiste à intégrer les charges de travail peu sollicitées dans une machine virtuelle déjà active. Notre système de suivi des tickets disposait d'une machine virtuelle entière, avec sa propre allocation de CPU et 1 Go de mémoire, pour un service utilisé quelques fois par jour par seulement trois personnes. Le déplacer à côté d'une infrastructure web existante a libéré cette allocation et a permis à la machine virtuelle de destination de gagner environ 480 Mo de mémoire résidente répartis sur deux conteneurs.

La rigueur qui garantit la sécurité de cette opération consiste à mettre hors service correctement la source au lieu de la laisser en fonctionnement. Nous avons configuré les anciens conteneurs pour qu'ils ne redémarrent pas, nous les avons arrêtés, nous avons laissé un fichier texte dans le répertoire indiquant l'emplacement actuel du service, puis nous avons éteint la machine virtuelle en désactivant le démarrage automatique. Ce point de restauration complet est ainsi préservé et ne peut pas redémarrer discrètement après un redémarrage de l'hôte et commencer à accepter des écritures que la nouvelle instance ne verra jamais. Les doublons divergents sont la cause classique d'une migration qui, bien que réussie, peut se transformer en incident de perte de données un mois plus tard.

Redimensionnement d'un disque virtuel saturé

À mi-chemin, l'espace de stockage de destination s'est avéré insuffisant. Son volume était de 9,6 Go, dont 1,5 Go libres, et nous étions sur le point d'ajouter une image de 816 Mo ainsi que 123 Mo de données d'application. Sur un NAS physique, l'opération s'arrête là, en attendant la livraison de nouveaux disques. Sur VDSM, il s'agit d'un champ texte.

Ouvrez les paramètres de l'invité dans Virtual Machine Manager, accédez à l'onglet Stockage, saisissez la nouvelle taille et cliquez sur OK. Il n'est pas nécessaire de mettre le système invité hors service pour cela. Le disque virtuel s'agrandit pendant que la machine continue de fonctionner, ce qui rend l'expérience fondamentalement différente de l'ajout de capacité à un matériel physique. Il est essentiel de retenir qu'un disque virtuel ne peut que s'agrandir, jamais se réduire ; il est donc impossible de revenir en arrière et il n'y a aucune raison d'hésiter sur la taille du disque.

Ce qui rend la migration véritablement indolore, c'est ce qui se passe au sein de la machine virtuelle. DSM étend automatiquement la partition et le système de fichiers pour occuper tout l'espace disponible. Nul besoin d'exécuter l'assistant Gestionnaire de stockage, de modifier la table de partitions, de reconstruire un volume ou de migrer des données. Notre volume est passé de 9,6 Go (dont 1,5 Go libres) à 20 Go (dont 13 Go libres), et les conteneurs ont continué de fonctionner sans problème. C'est là le principal argument en faveur du déploiement d'un service sur VDSM plutôt que sur du matériel nu : une erreur de dimensionnement est facile à corriger par la suite.

Ce que l'assistant IA a réellement fait

Il est important d'être précis, car l'affirmation “ une IA a déplacé mon serveur ” suscite à la fois trop et pas assez de crédulité. L'assistant n'avait aucune intuition miraculeuse. Il disposait d'un accès shell aux deux machines virtuelles VDSM et procédait de manière systématique, contrairement à ce qu'un humain fatigué en fin de journée ferait généralement.

L'action la plus précieuse qu'il ait réalisée a été d'exécuter `docker diff` avant toute modification, de constater 6 764 fichiers modifiés et de refuser le plan d'exécution évident. Une personne suivant le fichier Compose n'aurait eu aucune raison d'exécuter cette commande. La deuxième action la plus précieuse a été la vérification : après l'importation, il a compté les tables, les tickets, les projets, les entrées de journal et les pièces jointes des deux côtés, vérifié que chaque fichier joint existait sur le disque, listé les versions des plugins enregistrées par l'application et confirmé l'absence de migrations de base de données en attente. C'est une liste de vérification fastidieuse, et ce sont précisément les listes de vérification fastidieuses qu'on a tendance à ignorer à 17 h.

Ce qui manquait encore, c'était une évaluation humaine des conséquences. Redémarrer une machine virtuelle VDSM pour augmenter sa mémoire impliquait l'indisponibilité d'un site web en production ; une telle décision devait être discutée et non présumée. Il en va de même pour toute suppression de données. Considérez l'assistant comme une paire de mains extrêmement rapide et efficace, toujours prête à vérifier, et gardez pour vous les décisions irréversibles.

Où trouver plus de ressources officielles

Virtual Machine Manager, le paquet qui héberge toutes les machines virtuelles VDSM, est présent dans DSM depuis des années et est largement documenté. Ces trois tutoriels expliquent comment installer le paquet, créer une machine virtuelle et présentent l'interface générale que vous utiliserez.

Limites à connaître avant de confier la production à VDSM

Premièrement, la mémoire est bien plus souvent le facteur limitant que le processeur. Notre machine virtuelle de destination disposait de 2 Go de RAM et utilisait déjà l'espace d'échange avant même que nous n'y ajoutions quoi que ce soit. Une deuxième application et une deuxième base de données nécessitaient environ 480 Mo supplémentaires ; nous avons donc porté la mémoire à 4 Go. Vérifiez la mémoire disponible sur la machine de destination avant de planifier la migration, et non après.

Deuxièmement, un disque virtuel VDSM s'agrandit, mais ne se réduit jamais. En cas de surdimensionnement, il est impossible de récupérer l'espace excédentaire en réduisant sa taille ; la seule solution pour obtenir un disque plus petit est de créer une nouvelle machine virtuelle et d'y migrer. Choisissez une taille qui vous conviendra encore dans deux ans.

Troisièmement, les licences. Un invité est inclus avec le NAS ; chaque invité supplémentaire nécessite sa propre licence. Licence Virtual DSM. Le clustering sur plusieurs unités NAS, la migration en direct et la conservation plus étendue des snapshots sont des fonctionnalités importantes. VMM Pro Privilégiez les fonctionnalités aux options standard. Si votre plan de regroupement prévoit de diviser un hébergement occupé en quatre hébergements plus calmes, tenez-en compte dans le prix avant de le concevoir.

Évaluer correctement la taille d'un invité est une tâche en soi : Comment dimensionner correctement une machine virtuelle de production avec VMM Pro.

Quatrièmement, les scénarios à éviter. Ne placez pas le disque virtuel d'une machine virtuelle sur le même volume physique que celui utilisé pour vos sauvegardes et ne considérez pas cela comme une sauvegarde. N'exécutez pas une base de données avec des écritures importantes et soutenues sur une machine virtuelle partageant des disques durs avec un serveur de fichiers très sollicité. Ne considérez pas VDSM comme un substitut à une seconde machine, car si l'hôte tombe en panne, toutes les machines virtuelles qui y sont exécutées s'arrêteront simultanément. Enfin, ne migrez pas un conteneur que vous n'avez jamais inspecté, pour les raisons exposées dans la section relative au fichier Compose ci-dessus.

Cinquièmement, les identifiants. Une migration modifie les mots de passe de la base de données, les variables d'environnement et les fichiers de configuration. Dans notre cas, un fichier Compose contenant des identifiants de base de données en clair a été déplacé ; il a donc été placé délibérément en dehors du répertoire racine du serveur web. Un fichier Compose laissé à la racine du serveur web est téléchargeable par quiconque devine son nom, et c'est malheureusement une méthode courante de fuite d'identifiants. Si vous laissez un assistant exécuter un script de migration, vérifiez l'emplacement des fichiers qu'il écrit. Une fois la migration terminée, désactivez le compte créé pour l'assistant plutôt que de laisser un compte administrateur actif.

Sixièmement, effectuez une capture instantanée avant toute modification. Une capture instantanée VDSM dans Virtual Machine Manager ne prend que quelques secondes, est disponible sans licence Pro et permet de restaurer presque chaque erreur mentionnée dans cet article en deux minutes. C'est l'étape indispensable à ajouter à tout plan de migration, qu'il soit saisi par un humain ou un assistant.

Enfin, mieux vaut vérifier que supposer. Chaque affirmation de cet article a été vérifiée sur le système en fonctionnement : nombre de tables des deux côtés, présence des fichiers joints sur le disque, versions des plugins enregistrées par l’application, absence de migrations en cours et redémarrage complet de la pile pour confirmer son bon fonctionnement. Une migration n’est pas terminée lorsque le service répond. Elle l’est lorsqu’il est prouvé qu’elle survit à un redémarrage de la machine virtuelle VDSM et que l’ancienne copie ne peut plus accepter d’écritures.

Note concernant l'obtention de ces licences, puisque c'est notre spécialité : SynoPower Club vend des licences Synology avec livraison instantanée des clés 24 h/24 et 7 j/7. Les deux points importants ici sont : Licence Virtual DSM, dont vous avez besoin pour chaque invité supplémentaire après le premier invité gratuit, et le Licence VMM Pro si vous souhaitez le clustering, la migration à chaud ou 255 snapshots par invité au lieu de 32. catalogue de licences complet Cela inclut également les modèles Surveillance Station et MailPlus.

Références

• SynoPower Club, nos guides NAS Synology et nos tests de caméras
• Synology — Virtual Machine Manager, la présentation officielle du package qui exécute VDSM
• Centre de connaissances Synology — Aide Virtual Machine Manager, création et paramètres des invités
• Docker — commit de conteneur Docker, la commande derrière la première étape
• Docker — enregistrement d'images Docker, utilisé pour diffuser l'image entre les invités

Questions fréquemment posées