Synology VDSM: AI を活用した Docker の移動と仮想ディスクのサイズ変更 (2026)

仮想NASは、一度インストールして午後いっぱいいじってみたら、所有していることを忘れてしまうような機能の一つです。これは残念なことです。なぜなら、Synology VDSM（Virtual Machine Manager内で動作するVirtual DSM）は、小規模なセルフホスティングにおける最も厄介な2つの問題を静かに解決してくれるからです。1つ目は、Dockerスタックをマシン間で移動するには、通常、面倒な作業に一晩かかることです。2つ目は、仮想ディスクの容量が不足すると、ほとんどの人が全体を再構築する必要があると考えることです。VDSMではどちらも当てはまりません。このガイドでは、約35分で実行した実際の移行について説明します。5つのプラグインを備えた社内Redmine課題追跡システムを、1つのVDSMゲストから別のゲストに移行し、AIアシスタントがシェルを操作しました。途中で移行先のディスク容量が不足したため、仮想ディスクを10GBから20GBに拡張して作業を続行しました。以下は実際に起こったことであり、アプリケーションを静かに破壊してしまう可能性のある落とし穴も含まれています。

SynoPower Clubポイント：多くの人がNASでの仮想化を諦めてしまうのを見てきました。それは、仮想化はラボ環境向けであって、実際の業務には向かないと考えているからです。この記事で紹介した移行は、3人の同僚が毎日使用しているチケットシステムという、まさに実際の業務でした。そして、私を驚かせたのはAIではなく、VDSMがいかに手間のかからないものだったかということです。ハイパーバイザーのライセンスも、別の管理サーバーも、互換性のないフォーマット間のエクスポート/インポートの手間も一切不要です。ゲストOSが作業中にディスク容量不足になった時も、実行中のテキストフィールドに大きな数値を入力するだけで解決できました。作業全体は35分で完了し、誰も気づかなかった唯一の停止時間は、無関係なウェブサイトで90秒間発生しただけでした。もしあなたが既にメモリに余裕のあるSynologyをお持ちなら、パッケージを1つインストールするだけで、この作業を完了できます。

Synology VDSMとは何ですか？

VDSMはSynologyのVirtual DSMです。物理NAS上のVirtual Machine Manager内でゲストOSとして動作するDiskStation Managerの完全なコピーです。まるで独立したNASのように動作します。独自のIPアドレス、独自のDSMログイン、独自のパッケージ、独自のコンテナマネージャを備えています。ネットワークの観点から見ると、LAN上に別のSynologyが存在するだけです。ハードウェアの観点から見ると、既に購入済みの機器上で動作するプロセスが1つ増えただけです。

実用的な利点は、分離性にある。すべてのサービスをホスト上で直接実行すると、1つのコンテナの動作不良によって、オフィス全体が依存しているファイルサーバーがリソース不足に陥る可能性がある。ワークロードをVDSMゲストに分散させることで、各ゲストにメモリ上限、CPU割り当て、および専用ディスクが割り当てられ、他のゲストに影響を与えることなく1つを再起動できる。

Virtual Machine ManagerをサポートするすべてのNASには、1つのVDSMライセンスが無料で付属しています。2番目以降のゲストを実行するには、 有料Virtual DSMライセンス それぞれ。この記事のすべてを実行するには、その1つの無料インスタンスで十分です。そのため、多くの人が既にこの機能を所有しているにもかかわらず、一度も有効にしていないのです。後でライセンスを追加、マッピング、またはマッピング解除する必要がある場合は、次のチュートリアルを参照してください。 VDSMライセンスの管理.

VDSMとVirtual DSMは同じものを指す2つの名称です。Synologyの公式ドキュメントでは正式名称が使われていますが、ほとんどのユーザーは略称を使っています。この略称は、oVirt仮想化プロジェクトの無関係なコンポーネントとも共有されているため、Synology NASでは常にVirtual DSMを意味します。

有料ライセンスは、一般的に想像されるものとは異なります。ライセンス1つにつき、ゲストOSが1台追加され、Virtual DSMソフトウェアの3年間のアップグレードが含まれます。仮想マシンは有効期限がありません。3年後も、新しいアップデートなしで動作し続けます。新しいキーをアクティベートすると、さらに3年間のアップデートが開始されます。キーは一度に1台のSynology NASでのみ有効で、追加時にはNASがオンラインである必要があります。

VDSMゲストの要件は控えめで、Synologyはそれをリストアップしています。 Virtual Machine Managerの仕様:

• 仮想ディスクはBtrfsボリューム上に配置する必要があります。Virtual Machine Managerはext4上にゲストOSを保存しません。
• NAS自体が仮想マシンを実行するには、2GB以上のメモリが必要です。
• 各ゲストOSは少なくとも1GBのメモリを必要とし、実際のワークロードではさらに多くのメモリが必要になります。
• 1台のモデルが快適に処理できるゲストの数は、そのCPUと搭載されているメモリ容量によって決まります。

ゲストOSは、ベアメタル上のDSMと全く同じではありません。3つの要素が欠けており、それらはすべて物理的なハードウェアに関連しています。

• USBパススルー機能は利用できないため、NASのUSBポートに接続されたデバイスをゲストに渡すことはできません。
• コントロールパネルの「外部デバイス」と「ハードウェアと電源」のページがありません。
• ゲストOS内では、無線ドングル、MTU設定、リンクアグリゲーション（LACP）はサポートされていません。物理ネットワークはホストOSが管理します。

これらのことは、NASを導入する通常の理由には何ら影響を与えません。ファイルサービス、Docker、メールサーバー、本番システムのステージングコピーなどは、すべて独立したNAS上で動作する場合と同様に機能します。

Synology VDSMと2台目の物理NAS：どちらが必要ですか？

正直に言えば、仮想環境の方が優れているというわけではありません。柔軟性と耐久性のトレードオフです。物理サーバーは、1台目の障害が発生しても2台目が稼働し続けますが、VDSMゲストはそうはいきません。ゲスト環境を利用することで得られるメリットは、サーバー全体の作成、サイズ変更、スナップショット作成、移動を、数日ではなく数分で行えることです。

	VDSMゲスト	2つ目の物理的なNAS
追加費用	最初のゲストは無料、その後はライセンスが必要です	NAS全体とドライブ
準備時間	分	配送日数を含めると、
CPU、RAM、またはディスクのサイズを変更する	フィールドを編集し、ゲストを再起動します	新しいハードウェアを購入する
ホストハードウェアの障害にも耐える	いいえ	はい
スナップショットとクローン	Virtual Machine Managerに組み込まれています	適用できない
別のNASに移動する	ゲストOSを移行または複製する	物理的に移動させる
最適	サービスの分離、ステージング、小規模サーバーの統合	バックアップターゲットと真の冗長性

この作業に関しては、選択肢は明白でした。使用頻度の低い課題追跡システム（専用のVDSMゲストが割り当てられていた）を、既にウェブサイトを稼働させており、余裕のある容量を持つゲストに統合するだけだったからです。これには新しいハードウェアは一切必要ありません。必要なのは10分程度の時間とちょっとした注意だけです。

始める前に必要なもの

まず最初に、アシスタントに自分のログイン情報を渡すのではなく、アシスタント専用のログイン情報を与えてください。DSMでコントロールパネルを開き、「ユーザーとグループ」に移動して「作成」をクリックします。分かりやすい名前を付けてください。 クロード 説明付き AI制御 そして、DSMに強力なランダムパスワードを生成させましょう。

次の画面で、 管理者. これは必須です。DSM では、管理者グループのメンバーのみが SSH 経由でログインできるため、そのグループ外のアカウントはシェルにアクセスできません。両方の VDSM ゲストで同じ操作を行い、コントロール パネルの「ターミナルと SNMP」で SSH が有効になっていることを確認してください。

作業が完了したら、アカウントを無効にしてください。 別アカウントを作成する最大のメリットはまさにそこにあります。コントロールパネルでユーザーを編集して無効にするか、完全に削除すれば、自分の認証情報に触れることなくワンクリックでアクセス権を取り消すことができます。アシスタントが行ったすべての操作は、まさにその目的のために存在するログインアカウントに紐づけられます。かつて便利だったからといって、管理者アカウントを永続的に有効にしたまま放置しておくと、小規模な組織では、誰も許可したことを覚えていないアクセス権が蓄積されてしまうのです。

VDSMゲストが2台あり、両方でSSHが有効になっており、宛先にContainer Managerがインストールされています。また、ほとんどの人が初めて試す際に陥る重要な点として、DockerバイナリはDSM内のデフォルトのPATHには含まれていないということを知っておく必要があります。パッケージバイナリはパッケージディレクトリ内に存在するため、すべてのコマンドにはフルパスまたはシェルエイリアスが必要です。

乗り継ぎの途中で慌てて確認するのではなく、出発前に目的地に空きがあるかどうかを確認してください。以下のコマンドは出発前のチェック手順全体であり、VDSM対応のどのゲストでも同じように実行できます。

その前に、もう一つだけ。 Virtual Machine Managerにいる両方のゲストのスナップショットを撮る. スナップショットは、Pro版だけでなくVirtual Machine Managerの無料版にも含まれており、ゲストOSごとに最大32個のスナップショットを保持できます。VDSMスナップショットはマシン全体をキャプチャするため、インポートが失敗したり、コマンドが意図しない動作をしたりした場合でも、ゲストOSを再構築するのではなく、ロールバックできます。所要時間はわずか数秒で、このプロセス全体の中で最も安価な保険と言えるでしょう。ソース側と宛先側の両方でスナップショットを取得してください。ソース側はバックアップとして機能します。

# Docker は DSM の PATH にありません - フルパス D=/volume1/@appstore/ContainerManager/usr/bin/docker を使用してください # 何が実行されていて、何から構築されていますか? sudo $D ps -a sudo $D images # 宛先ボリュームにはどれくらいの空き容量がありますか? df -h /volume1 # 宛先ゲストには実際にどれくらいの空きメモリがありますか? free -m

VDSMのDocker移行を4つのステップで実現

以下は私たちが実行した4つの手順です。これらの手順は、VDSMゲスト間で移行する必要のあるあらゆるコンテナスタックに適用できます。重要なのは手順の順序です。まずアプリケーションコンテナを停止することで、ダンプ中にデータベースへの書き込みが行われないようにし、データベースコンテナは起動したままにして、クリーンなダンプを実行できるようにします。

Compose ファイルがコンテナ全体ではない理由

ここに落とし穴があり、それだけでも入場料を払う価値があります。Redmineスタックのcomposeファイルでは、アップロードされたファイル用とデータベース用の2つのバインドマウントが宣言されていました。このファイルを読むと、新しいゲスト上でスタックを再構築するには、2つのディレクトリをコピーしてdocker compose upを実行すればよいと当然のように考えます。

そうはなりませんでした。5つのプラグイン、それらのプラグインが取り込んだRuby gem、メール設定、そして編集されたいくつかの初期化ファイルが、長年にわたって実行中のコンテナに直接インストールされていました。それらはどれもボリュームには配置されていませんでした。たった1つのコマンドで、その深刻さが分かりました。

# コンテナと、そのコンテナの元となったイメージとの間で、ファイルの違いはいくつありますか？ sudo $D diff Redmine | wc -l 6764 # コンテナ内に存在するプラグイン（ボリュームによるバックアップは一切なし） sudo $D exec Redmine ls /usr/src/redmine/plugins

最新の公式イメージをプルした場合、これらのプラグインが一切含まれていないコンテナが生成され、移行によって作成された144個のテーブルがまだ保持されているデータベースを指すことになります。アプリケーションは大きなエラーメッセージを表示することなく、起動してほぼ正常に動作しているように見えた後、診断が非常に困難な形でエラーが発生します。実行中のコンテナをイメージにコミットすることで、より大きな転送量という代償を伴いますが、この問題を完全に回避できます。2つのVDSMゲスト間のLANでは、そのコストは約1分なので、常にこのトレードオフを受け入れるべきです。

小規模チームがVDSMを使用してサーバーを統合する方法

この移行がたどるパターンは、ほとんどの小規模チームが最終的に必要とするものです。数年かけて、単目的のゲストが蓄積されます。1つはWiki用、1つはチケットトラッカー用、1つは監視ダッシュボード用です（これは、 ホーム データセンターのウォークスルーそれぞれは製造当時は余裕をもって設計されていたが、現在では当初の想定のほんの一部しか稼働しておらず、ホスト側は過剰な負荷がかかっているため、全体的にやや動作が遅く感じられる。

VDSMによる統合とは、稼働中のゲストOSに、処理頻度の低いワークロードを統合することを意味します。当社のチケットトラッカーは、3人のユーザーが1日に数回アクセスするサービスにもかかわらず、専用のCPUと1GBのメモリを持つゲストOSを占有していました。これを既存のWebスタックの隣に移動することで、そのメモリ割り当てが解放され、2つのコンテナにまたがる常駐メモリの消費量は約480MB削減されました。

これを安全にする規律は、ソースを稼働させたままにするのではなく、適切に廃止することです。古いコンテナの再起動ポリシーを「いいえ」に設定し、停止し、サービスが現在どこにあるかを説明するテキストファイルをディレクトリに残し、自動起動を無効にしてゲストをシャットダウンしました。完全なロールバックポイントが維持され、ホストの再起動後に静かに復活して、新しいインスタンスが決して見ることのない書き込みを受け入れることはありません。不整合な重複は、整然とした移行が1か月後にデータ損失事故に発展する典型的な原因です。

容量不足になった仮想ディスクのサイズ変更

途中で、保存先の容量が不足しました。容量は9.6GBで、空き容量は1.5GBでしたが、816MBのイメージファイルと123MBのアプリケーションデータを追加しようとしていました。物理NASでは、新しいドライブが届くまでここで作業は中断されます。VDSMでは、これはテキストフィールドです。

Virtual Machine Managerでゲストの設定を開き、「ストレージ」タブに移動して、新しいサイズを入力し、「OK」をクリックします。 このため、ゲストのアクセスを停止する必要はありません。 仮想ディスクはマシンが稼働している間も容量が増加するため、これはハードウェアに容量を追加するのとは根本的に異なる体験となります。覚えておくべき重要なルールは、仮想ディスクは容量を増やすことはできても減らすことはできないため、元に戻す機能はなく、容量の数値を遠慮する必要はありません。

本当に手間がかからないのは、ゲストOS内部で何が起こるかによるものです。DSMはパーティションとファイルシステムを自動的に拡張し、新しい領域を埋めます。ストレージマネージャウィザードを実行する必要も、パーティションテーブルを編集する必要も、ボリュームを再構築する必要も、データを移行する必要もありません。ボリュームは9.6GB（空き容量1.5GB）から20GB（空き容量13GB）に拡張され、コンテナはそのまま動作し続けました。これが、ベアメタルではなくVDSM上にサービスを配置する最大のメリットです。サイズ設定を間違えても、後で簡単に修正できるからです。

AIアシスタントが実際に行ったこと

ここで正確に述べておく必要がある。「AIがサーバーを移動した」という説明は、信憑性が高すぎると同時に低すぎるという両極端な印象を与えるからだ。アシスタントに魔法のような洞察力があったわけではない。VDSMの2人のゲストに対してシェル（監視システム）を実装し、仕事の終わりに疲れた人間が通常行わないような体系的な方法で処理を行ったのだ。

最も価値のあることは、何も変更する前に docker diff を実行し、6,764 個の変更されたファイルを検出し、明らかな計画を拒否したことです。compose ファイルに従っていれば、このコマンドを実行する理由はなかったでしょう。2 番目に価値のあることは検証です。インポート後、両側のテーブル、課題、プロジェクト、ジャーナルエントリ、添付ファイルをカウントし、すべての添付ファイルがディスク上に存在することを確認し、アプリケーションが登録したプラグインのバージョンを一覧表示し、保留中のデータベース移行がないことを確認しました。これは面倒なチェックリストであり、面倒なチェックリストは午後 5 時になるとまさにスキップされるものです。

人間が依然として必要としていたのは、結果に対する判断力だった。メモリを追加するためにVDSMゲストを再起動するということは、稼働中のウェブサイトを停止させることを意味し、それは当然のこととして判断するのではなく、確認すべき事項である。何かを削除する場合も同様だ。アシスタントは、チェックに飽きることのない、非常に高速で文字通りの「手」だと考え、取り返しのつかない操作は自分で行うべきだ。

その他の公式資料の入手先

すべてのVDSMゲストをホストするパッケージであるVirtual Machine Managerは、長年にわたりDSMに組み込まれており、十分に解説されています。この3つのチュートリアルでは、パッケージのインストール、ゲストの作成、および作業に使用するインターフェースの一般的な構成について説明します。

VDSMを制作に信頼する前に知っておくべき限界

まず、メモリはCPUよりもはるかに頻繁にボトルネックとなります。移行先のゲストOSは2GBのメモリしかなく、追加する前から既にスワップ領域が使用されていました。2つ目のアプリケーションと2つ目のデータベースを追加すると、さらに約480MBのメモリが必要になったため、メモリを4GBに増やしました。移行計画を立てる前に、移行先の空きメモリを確認してください。移行後に確認するのは避けてください。

第二に、VDSM仮想ディスクは容量が増えることはあっても、縮小することはありません。過剰にプロビジョニングした場合、フィールドを編集して容量を縮小しても、その分を取り戻すことはできません。ディスク容量を小さくするには、新しいゲストOSを構築してそこに移行するしか方法はありません。2年後も満足できる容量を選択してください。

3つ目はライセンスです。NASには1つのゲストライセンスが含まれていますが、追加のゲストごとに別途ライセンスが必要です。 Virtual DSMライセンス. 複数のNASユニットにまたがるクラスタリング、ライブマイグレーション、およびより大きなスナップショット保持は VMM Pro 標準的な機能ではなく、特別な機能を備えた部屋を選びましょう。もし、忙しいゲスト1人を4つの部屋に分けるような統合プランを考えているなら、設計する前にその費用を見積もっておきましょう。

ゲストのサイズを適切に調整することは、それ自体が重要な役割です。 VMM Proを使用して本番環境のVMのサイズを適切に調整する方法.

第4に、避けるべきシナリオについて説明します。ゲストの仮想ディスクをバックアップ先の物理ボリュームと同じ場所に配置して、それをバックアップと呼ばないでください。ビジーなファイルサーバーと回転ディスクを共有するゲスト上で、書き込み頻度の高いデータベースを実行しないでください。VDSMを2台目のマシンの代わりとして扱わないでください。ホストがダウンすると、その上のすべてのゲストも同時にダウンしてしまうからです。また、上記のcompose-fileのセクションで説明した理由から、一度も検査したことのないコンテナを移行しないでください。

5つ目は認証情報です。移行作業では、データベースのパスワード、環境変数、設定ファイルなどが影響を受けます。今回の移行では、平文のデータベース認証情報を含むcomposeファイルを移動したため、意図的にWebサーバーのドキュメントルートの外に配置しました。ドキュメントルート内にcomposeファイルが残っていると、ファイル名を推測した人なら誰でもダウンロードできてしまい、認証情報が漏洩する非常に一般的な原因となります。アシスタントに移行スクリプトを作成させる場合は、ファイルがどこに書き込まれているかを確認してください。また、作業が完了したら、管理者アカウントをそのまま残しておくのではなく、アシスタント用に作成したアカウントを無効化してください。

6つ目は、何も操作する前にスナップショットを作成することです。Virtual Machine ManagerのVDSMスナップショットは数秒で作成でき、Proライセンスなしでも利用可能です。この記事で挙げたほとんどすべてのミスを、わずか2分でロールバックできる状態にしてくれます。人間が入力する場合でもアシスタントが入力する場合でも、移行手順書に追加する価値のある唯一のステップです。

最後に、憶測ではなく検証を心がけてください。この記事に記載されているすべての主張は、実行中のシステムに対して検証されています。具体的には、両側のテーブル数、ディスク上の添付ファイルの有無、アプリケーションに登録されているプラグインのバージョン、保留中の移行がないこと、そしてスタックの完全な再起動によって、システムが自動的に復旧することを証明しています。移行は、サービスが応答した時点で完了したわけではありません。VDSMゲストの再起動後も移行が継続し、かつ古いコピーが書き込みを受け付けなくなった時点で完了したと言えます。

ライセンスの入手先について、弊社が行っていることなので補足しておきます。SynoPower ClubはSynologyライセンスを24時間体制で即時キー配信で販売しています。ここで重要なのは次の2つです。 Virtual DSMライセンス, 無料のゲスト1人を超えるゲスト全員に必要なもの、そして VMM Proライセンス クラスタリング、ライブマイグレーション、またはゲストごとに32個ではなく255個のスナップショットが必要な場合は、 ライセンスカタログ全文 Surveillance StationとMailPlusも対象としています。

参考文献

• SynoPower Club, Synology NASガイドとカメラレビュー
• Synology — Virtual Machine Manager, VDSMを実行するパッケージの公式概要
• Synology ナレッジセンター — Virtual Machine Manager ヘルプ, ゲストの作成と設定
• Docker — Dockerコンテナのコミット, ステップ1の背後にあるコマンド
• Docker — Dockerイメージの保存, ゲスト間で画像をストリーミングするために使用されます

よくある質問