Virtual DSMをDockerで検証する前に押さえる条件
vdsm/virtual-dsmは実運用向けに使える実用的なオープンソース実装で、再利用可能な導入ルートを持つプロジェクトです。
ひと目でわかる
- これは何？
- Dockerコンテナ内でVirtual DSMを動かすプロジェクト。KVM、ディスク、macvlan、GPU、DSMのライセンス条件を具体的に確認する。
- 誰に向いている？
- Virtual DSMは、KVMへアクセスできるLinuxホスト、またはネスト仮想化を有効にしたWindows 11で、DockerコンテナとしてDSMを検証したい人向けです。まず`/dev/kvm`、RAM 1GB以上、空き容量16GB以上を確認し、テスト用ストレージでport 5000の初回インストールと再起動を試してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 13 日前です。
- 何の言語で書かれている？
- 主に Shell です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
コンテナ内でDSMを動かす構成
READMEはVirtual DSMをDockerコンテナで実行し、インストールファイルを自動取得し、WebからDSMデスクトップへ接続するプロジェクトと説明しています。KVMアクセラレーションによるネイティブに近い性能、CPU・メモリ・ストレージの割り当て、複数ディスク、物理ディスクパススルー、メモリバルーニング、NATやmacvlanなどのネットワークが機能です。
これは一般的なDockerアプリのようにCPUとボリュームだけで動く構成ではありません。`/dev/kvm`、`/dev/net/tun`、`NET_ADMIN`などホスト側のデバイスと権限を扱います。コンテナが起動してもDSMのインストール完了やNAS機能の正常性を意味しないため、初回セットアップから再起動まで別々に確認します。
ホスト要件とKVMの入口
対応要件はKVMをサポートするLinuxホスト上のDockerまたはPodman、またはネスト仮想化を有効にしたWindows 11のDocker DesktopやPodman Desktopです。最低1GBの利用可能RAMと16GBの空きディスク容量も記載されています。Linux、macOS、Windows 10のDocker DesktopはコンテナへKVMを提供しないため未対応です。
Linuxでは`cpu-checker`を導入して`kvm-ok`を実行し、`/dev/kvm`の存在を確認します。成功してもコンテナがKVMを利用できない場合は、READMEが一時的な切り分けとして`privileged: true`を挙げています。これは常用設定ではなく、権限やデバイスの原因を切り分けたら必要最小限へ戻します。
ComposeとCLIで最初の起動
Compose例では`vdsm/virtual-dsm`、`DISK_SIZE: "256G"`、`/dev/kvm`、`/dev/net/tun`、`NET_ADMIN`、port 5000、`./dsm:/storage`、停止猶予2分を指定します。CLI例も同じデバイスとストレージを渡し、port 5000を公開します。Kubernetesではリポジトリの`kubernetes.yml`を`kubectl apply`する例があります。
検証ではホストの専用ディレクトリを`/storage`へマウントし、`127.0.0.1:5000`でWeb画面を開きます。インストールが終わるまで待ち、ユーザー名とパスワードを設定してデスクトップへ入れること、コンテナを再起動して状態が残ることを確認します。Codespacesのリンクを本番環境の代替と解釈せず、KVM要件を実行基盤で確認します。
容量、CPU、メモリ、物理ディスク
`DISK_SIZE`は既定の256GBを拡張する設定で、`DISK2_SIZE`や`DISK3_SIZE`と`/storage2`、`/storage3`のボリュームで追加ディスクを作れます。`CPU_CORES`と`RAM_SIZE`で割り当てを変え、READMEの既定値は2コアと2GBです。既存ディスクの拡張については、データを失わず容量を増やせるという自己記載があります。
物理ディスクやパーティションを`devices`で渡す場合、READMEはファイルシステムのない空のデバイスを使うよう注意しています。誤ったデバイスを渡すと初期化対象を間違える危険があります。まず仮想ディスクで容量変更と再起動を試し、物理デバイスは識別子、マウント状態、バックアップを確認してから扱います。
ネットワークとGPUの具体的な制約
既定のbridgeはホストとIPを共有します。個別IPにはmacvlanを作り、サブネット、ゲートウェイ、IP範囲、親インターフェースを環境に合わせて設定します。macvlanではDockerホストからコンテナへ通信できないため、必要なら二つ目のmacvlanを作る回避策がREADMEにあります。DHCPモードでは`DHCP: "Y"`、`/dev/vhost-net`、device cgroup ruleを追加します。
IntelまたはAMD GPUは`GPU: "Y"`と`/dev/dri`、NVIDIAはNVIDIA Container ToolkitとGPU予約設定を使います。READMEはGPUでSynology Photosの顔認識を有効にできる一方、動画のハードウェアトランスコードはまだ提供しないと記載しています。ネットワークとGPUは便利さより、ホストの公開範囲とデバイス権限を先に評価します。
DSM版、差異、EULA、MIT
既定ではDSM 7.2をインストールし、別版は`.pat`のURLを`URL`へ指定するか、ローカルの`.pat`を`/boot.pat`へマウントします。Virtual Machine Managerは利用できず、Surveillance Stationの無料ライセンスも含まれないという標準DSMとの差異があります。版変更でデータを保持できるという説明はありますが、実データで試す前に複製を作ります。
READMEはコードのみを含みSynology所有素材を配布せず、著作権保護の回避を試みないと説明します。一方、Virtual DSMのインストールにはSynology EULAへの同意が必要で、非Synologyハードウェアへのインストールは許可されないため、公式Synology NAS上で実行するよう案内しています。MITライセンスの権利と免責はLICENSEで確認し、製品の利用許諾とは分けて判断します。
Virtual DSM固有の確認として、`kvm-ok`、`/dev/kvm`、`/dev/net/tun`、空き容量、RAMを先に検査します。`./dsm:/storage`へ専用ディレクトリをマウントし、port 5000でDSMのインストール完了、再起動後のデータ保持、容量拡張を試します。macvlanを選ぶ場合はDockerホストから到達できない制約を実測し、物理ディスクは空であることを確認してから渡します。
Virtual DSMをDockerで検証する前に押さえる条件の採用判断では、対象版のREADMEにある入力と出力を固定し、担当者が同じ手順を再実行できる状態で結果を残します。動いたという記録だけでなく、失敗条件、戻し方、ライセンス確認の結果も対象プロジェクトに結び付けて管理します。
編集部の結論
Virtual DSMは、KVMへアクセスできるLinuxホスト、またはネスト仮想化を有効にしたWindows 11で、DockerコンテナとしてDSMを検証したい人向けです。まず`/dev/kvm`、RAM 1GB以上、空き容量16GB以上を確認し、テスト用ストレージでport 5000の初回インストールと再起動を試してください。SynologyのEULAとハードウェア条件を確認できない場合は運用へ進めません。
コミュニティノート