Virtual DSM dans un conteneur Docker

Virtual DSM dans un conteneur Docker

Le projet se décrit comme Virtual DSM dans un conteneur Docker. Il est écrit en Shell et publié sous licence MIT. Le README indique que le conteneur exécute Virtual DSM, télécharge automatiquement les fichiers d'installation et offre un accès Web au bureau DSM. Il liste également des performances proches du natif avec l'accélération KVM, ainsi qu'une allocation personnalisable du CPU, de la mémoire et du stockage.

Exigences et hôtes pris en charge

Le README spécifie Docker ou Podman sur un hôte Linux avec support KVM, ou Docker Desktop ou Podman Desktop sur Windows 11 avec virtualisation imbriquée activée. Au moins 2 Go de RAM et 32 Go d'espace disque libre sont nécessaires. Docker Desktop sur Linux, macOS et Windows 10 n'est pas pris en charge car il ne fournit pas l'accès KVM aux conteneurs. Le README ne précise pas quelles fonctionnalités KVM ou quels modèles de CPU sont requis au-delà de la présence de /dev/kvm.

Démarrage avec Docker Compose, CLI ou Kubernetes

Le README fournit un exemple de service Docker Compose utilisant l'image vdsm/virtual-dsm. L'exemple définit DISK_SIZE sur 256G, transmet /dev/kvm et /dev/net/tun au conteneur, ajoute NET_ADMIN, mappe le port 5000 et monte ./dsm sur /storage. Une commande docker run avec les mêmes options est également montrée, ainsi qu'une URL kubectl apply pour un manifeste Kubernetes. Aucune instruction n'est donnée pour construire l'image à partir des sources.

Paramètres de stockage, de disque, de CPU et de GPU

La FAQ explique comment modifier l'emplacement de stockage en remplaçant le montage bind dans le fichier compose. La taille du disque est contrôlée par DISK_SIZE, et des disques supplémentaires peuvent être ajoutés avec DISK2_SIZE, DISK3_SIZE et les volumes correspondants. Les disques physiques ou partitions peuvent être passés directement via des entrées devices. Le CPU et la RAM sont définis avec CPU_CORES et RAM_SIZE, avec des valeurs par défaut de 2 cœurs et 2 Go. Le passage de GPU utilise GPU: "Y" et /dev/dri; le README indique que cela active la reconnaissance faciale dans Synology Photos mais ne fournit pas de transcodage matériel pour la vidéo.

Modes réseau et attribution d'adresse IP

Par défaut, le conteneur utilise le réseau bridge et partage l'adresse IP avec l'hôte. Pour lui attribuer une adresse individuelle, le README montre comment créer un réseau macvlan avec docker network create et y connecter le conteneur. Le README note que le conteneur est inaccessible depuis l'hôte Docker en raison de la conception de macvlan et suggère un second macvlan comme solution de contournement. Il décrit également un mode DHCP en définissant DHCP: "Y", en ajoutant /dev/vhost-net et une règle device_cgroup_rule, ce qui permet à DSM de demander une IP au routeur.

Choix de version et vérification de KVM

L'installation par défaut est la version 7.2 de DSM. Une version plus ancienne peut être installée en définissant URL sur un téléchargement de fichier .pat, ou en liant un fichier .pat local à /boot.pat, ce qui remplace URL. Le README indique qu'il est possible de changer de version tout en conservant les données. Pour vérifier KVM, il suggère d'installer cpu-checker et d'exécuter kvm-ok, puis de vérifier que /dev/kvm existe. Si kvm-ok réussit mais que le conteneur signale toujours que KVM est indisponible, il recommande de définir temporairement privileged: true pour exclure un problème de permission ou d'accès aux périphériques.

Différences avec le DSM standard et conditions légales

Le README liste deux différences par rapport au DSM standard : Virtual Machine Manager n'est pas disponible et Surveillance Station n'inclut aucune licence gratuite. Sur la question juridique, il indique que le projet ne contient que du code open source et ne distribue aucun matériel appartenant à Synology, ni ne tente de contourner les mesures de protection du droit d'auteur. Cependant, l'installation de Virtual DSM exige d'accepter l'EULA de Synology, qui n'autorise pas l'installation sur du matériel non Synology. Le README conseille donc d'exécuter le conteneur uniquement sur des NAS officiels Synology. La licence MIT accorde le droit d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre le logiciel, mais ne fournit aucune garantie et décline toute responsabilité.

Le périmètre réel de virtual-dsm

virtual-dsm répond au problème décrit dans le README, avec les limites que ce document expose. La présentation permet de comprendre le rôle du dépôt, mais elle ne vaut pas preuve pour les performances, la compatibilité ou la sécurité qui ne sont pas précisées. Le bon niveau de confiance vient des artefacts que le projet rend visibles et de la version examinée. Pour virtual-dsm, ce contrôle doit être consigné avec la version du dépôt, la commande exécutée et le résultat exact observé. Notez le fichier docker-compose.yml, les paramètres réellement utilisés et la différence entre le comportement attendu et celui obtenu. Cette trace est particulièrement utile lorsque KVM dépend d un service externe, d un système hôte ou d une autorisation locale. Elle permet de reprendre l essai sans transformer une démonstration ponctuelle en garantie générale. Les mainteneurs peuvent modifier l interface, le schéma ou les prérequis; relisez donc le README et les exemples liés avant une mise à jour. Toute décision d intégration doit rester limitée au périmètre que virtual-dsm documente effectivement.

Conclusion éditoriale

virtual-dsm s adresse aux utilisateurs dont le besoin correspond exactement au README. Il ne convient pas sans vérification du contexte d exécution : lancez docker compose up -d, examinez docker-compose.yml et observez KVM sur un cas représentatif avant de retenir ce dépôt.

Sources officielles

1. Official README
2. Project repository
3. Release notes