仮想化における最大の利点として、 VM ゲスト を移動できるという点があります。たとえば VM ホストサーバ でメンテナンスを実施しなければならないような場合や、 VM ホストサーバ の負荷が過剰である場合、ゲストを他の VM ホストサーバ に移行することができます。 KVM と Xen では 「ライブ」 マイグレーションにも対応していますので、これにより VM ゲスト を動作させたまま移行することもできます。
仮想マシン (VM) の移行に際しては、要件に応じて下記の 3 種類の方式から選択することができます。
移行元の VM を動作させたまま、設定とメモリ内容を移行先のホストに転送します。全ての転送が完了した時点で移行元の VM を一時停止し、移行先の VM を復元します。
ライブマイグレーションは、常に動作させておく必要のある VM を移行したい場合に有用です。
ライブマイグレーションを行う場合、 I/O 負荷やメモリページへの書き込みが非常に多くなります。このような場合は、非ライブマイグレーションやオフラインマイグレーションの使用をご検討ください。
いったん移行元の VM を一時停止して、設定とメモリを移行先のホストに転送します。転送完了後、移行先で VM を再開します。
非ライブマイグレーションは、ライブマイグレーションより信頼性の高い方式ではありますが、 VM にアクセスできなくなる時間が存在するという問題があります。このようなダウンタイムを許容できるシステムであれば、ライブマイグレーションの難しい VM には有用な選択肢となります。
VM の設定を移行先のホストにコピーするだけです。移行元の VM は停止させず、移行先の VM を復元させない方式です。
オフラインマイグレーションは、その時点で動作させていない VM を移行する際に使用します。
オフラインマイグレーションを行う場合、 --persistent
オプションを指定しておかなければなりません。
VM ゲスト を他の VM ホストサーバ に移行する場合は、下記の要件を満たす必要があります:
移行元と移行先のシステムが同じアーキテクチャであること。
NFS や iSCSI など、両方のマシンから同じストレージデバイスにアクセスできること。詳しくは 第12章 「高度なストレージ設定」 をお読みください。
なお、移行の時点で接続済みの CD-ROM やフロッピィディスクのイメージについても、両方のマシンからアクセスできるようにしなければなりません。ただし、これらは移行実施前に取り外しておくことができます。詳しくは 13.11項 「仮想マシンマネージャ を利用したフロッピィもしくは CD/DVD-ROM メディアの取り出しと交換」 をお読みください。
両方の VM ホストサーバ で libvirtd
を動作させ、かつ移行元と移行先の間でリモートの libvirt
接続を許可しておくこと。詳しくは 11.3項 「リモート接続の設定」 をお読みください。
移行先のホストでファイアウオールを動作させている場合は、移行時に使用するポートを開いておく必要があります。移行処理時に特に何も指定しない場合、 libvirt
では 49152:49215 の範囲からポート番号を選択します。 移行先のホスト でこのポート範囲の通信を許可するように設定するか、もしくは独自にポートを選択して許可し、移行処理時にそのポート番号を指定してください。
移行元と移行先のホストが、ネットワーク内の同じサブネットに属していること。異なるサブネットに属している場合、移行後に接続できなくなってしまいます。
移行元と移行先の VM ホストサーバ で、 qemu ユーザ, kvm グループ, qemu グループ, libvirt グループの UID や GID が一致していること。
移行先のホストで既に同名の VM ゲスト が設定されていないこと。同名の VM ゲスト が存在していて停止している場合、設定は上書きされてしまいます。
CPU モデルの設定で host cpu モデルを選択していないこと。
SATA ディスクデバイスを使用していないこと。
ファイルシステムのパススルー機能を使用していないこと。
VM ホストサーバ と VM ゲスト の間で適切な時刻維持機能が設定されていること。詳しくは 第19章 「VM ゲスト の時刻設定」 をお読みください。
VM ホストサーバ から VM ゲスト に対して、物理デバイスに直接アクセスできる機能を提供していないこと。現時点でのライブマイグレーションは、 PCI パススルーや SR-IOV を使用している場合、サポート対象外となります。ライブマイグレーションを使用したい場合は、ソフトウエアによる仮想化 (準仮想化または完全仮想化) をお使いください。
キャッシュモードを適切に設定していること。詳しくは 18.6項 「キャッシュモードとライブマイグレーションの関係」 をお読みください。
両方のホストでイメージディレクトリが同じパスであること。
全てのホストは同一レベルのマイクロコード (特に Spectre マイクロコード更新) が適用されていること。これは全てのホストで openSUSE Leap の最新版をインストールすることで実現できます。
仮想マシンマネージャ で VM ゲスト の移行を行う場合、どちらのマシンで処理を開始してもかまいません。移行元のホストで 仮想マシンマネージャ を実行してもかまいませんし、全く別のホストで実行してもかまいません。ただし、後者の場合は移行元と移行先の両方に接続できるように設定しておく必要があります。
まずは 仮想マシンマネージャ を起動し、移行元と移行先に接続します。移行元のホストでも移行先のホストでもない場所から 仮想マシンマネージャ を起動している場合は、両方のホストに接続してください。
移行したい VM ゲスト を選択して右クリックし、
を選択します。なお、対象のゲストが実行中か、もしくは一時停止されている必要があります。停止中の場合は移行できません。移行処理を高速化するためには、 VM ゲスト を一時停止するのが最適です。これは 16.1項 「移行の種類」 で説明している 「非ライブマイグレーション」 と同じ処理になります。
VM ゲスト の移行先となる
を選択します。移行先が表示されない場合は、移行先に対して接続を実施しているかどうかをご確認ください。移行先のホストに対する接続オプションを変更したい場合は、
内の , (IP アドレスまたはホスト名), をそれぞれ設定します。なお、 を指定した場合は の設定も行わなければなりません。また、
内では、恒久的な移行か一時的な移行かを選択することができます。一時的に移行するだけであれば、 を選択します。このほか、 cache="none"
/ 0_DIRECT
を使用しておらず、 VM ゲスト のストレージに対する一貫したビューが利用可能な場合にのみ動作します。
仮想マシンマネージャ の新しいバージョンでは、移行時の帯域設定に関する設定オプションが削除されています。帯域を指定して移行を行いたい場合は、 virsh
をお使いください。
移行を開始するには
を押します。移行処理が完了すると
ウインドウが閉じ、 仮想マシンマネージャ ウインドウ内の移行先ホスト内に VM ゲスト が表示されるようになります。なお、移行元の VM ゲスト についても、シャットダウン状態で残ります。virsh
による移行 #Edit sourceVM ゲスト を virsh
migrate
コマンドで移行するには、 VM ホストサーバ に対する直接のアクセスまたはリモートからのシェルアクセスが必要となります。これは、コマンドをホスト内で実行する必要があるためです。移行のコマンドは下記のように記述します:
>
virsh migrate [オプション] VM_ID_または名前 接続_URI [--migrateuri tcp://リモートホスト:ポート]
下記に主要なオプションを示します。完全な一覧を読みたい場合は、 virsh help migrate
コマンドを実行してください。
--live
ライブマイグレーションを実行します。このオプションを指定しない場合、ゲストは移行の際に一時停止します ( 「非ライブマイグレーション」 になります) 。
--suspend
ライブマイグレーションや非ライブマイグレーションで、移行先のホストを一時停止したままの状態にします。
--persistent
移行先のホストで恒久的な VM 移行を実施します。このオプションを指定しないと、 VM をシャットダウンした段階で virsh list --all
の一覧には表示されなくなります。
--undefinesource
このオプションを指定すると、移行が成功した時点で移行元のホストでの VM ゲスト の定義を削除します。なお、ゲストに接続されている仮想ディスクは削除されない ことに注意してください。
--parallel --parallel-connections 接続数
パラレルマイグレーション (並行移行) は、単一スレッドの移行処理ではネットワークの帯域を使い切れないような場合に使用するもので、移行処理をより高速化する目的で使用されます。たとえば 40 GB のネットワークインターフェイスを持つホストの場合、スレッドを 4 つにすることでネットワーク帯域を埋めることができるようになります。またパラレルマイグレーションを使用することで、移行処理に必要な巨大なメモリ占有の時間を減らすこともできます。
下記の例では、移行元を mercury.example.com とし、移行先を jupiter.example.com とした移行処理を実行しています。また、 VM ゲスト の名前は opensuse131
で、 ID が 37
である場合の例となります。
>
virsh migrate 37 qemu+ssh://tux@jupiter.example.com/system
>
virsh migrate --live opensuse131 qemu+ssh://tux@jupiter.example.com/system
>
virsh migrate --live --persistent --undefinesource 37 \
qemu+tls://tux@jupiter.example.com/system
>
virsh migrate opensuse131 qemu+ssh://tux@jupiter.example.com/system \
--migrateuri tcp://@jupiter.example.com:49152
>
virsh migrate --live --persistent --copy-storage-all \
opensuse156 qemu+ssh://tux@jupiter.example.com/system
--copy-storage-all
オプションを指定して VM のストレージを転送する場合、ストレージは libvirt
のストレージプール内に存在していなければなりません。また、移行先でも同じ種類かつ同じ名前のストレージプールが存在していなければなりません。
移行元でストレージプールの XML 形式出力を行いたい場合は、下記のようなコマンドを入力して実行します:
>
sudo
virsh pool-dumpxml VM_名 > EXAMPLE_POOL.xml
移行先のホストでストレージプールを作成して開始するには、上記で出力した XML ファイルをコピーしてから下記のコマンドを実行します:
>
sudo
virsh pool-define EXAMPLE_POOL.xml>
sudo
virsh pool-start EXAMPLE_VM
既定では、 virsh migrate
は移行先のホスト内に一時的な VM ゲスト のコピーを作成します。移行元のホストには元のゲストの設定が残り、ゲストはシャットダウン状態になります。また、移行先のゲストをシャットダウンすると、一時的な移行の場合は削除されてしまいます。
移行先のホストで恒久的に動作させたい場合は、 --persistent
オプションを指定してください。この場合も移行元のホストには、ゲストがシャットダウンした状態で残されます。 --persistent
に加えて --undefinesource
を指定することで、移行先のホストに恒久的な移行を実施し、移行元のゲストを削除するようになります。
なお、 --persistent
オプションを指定せずに --undefinesource
オプションを指定してしまうと、移行先のホストではゲストをシャットダウンしたタイミングで設定が失われてしまうため、両方のホストからゲストが削除されてしまうことに注意してください。
まずはホスト間でゲストイメージを共有するため、ストレージのエクスポート (公開) を実施します。一般的には NFS サーバを利用します。下記の例では、 /volume1/VM
ディレクトリを 10.0.1.0/24 のネットワーク内にある全てのホストに対して提供します。具体的には、 root ユーザで /etc/exports
ファイルを編集して、下記の内容を追記します:
/volume1/VM 10.0.1.0/24 (rw,sync,no_root_squash)
設定変更後は NFS サーバの再起動が必要です:
>
sudo
systemctl restart nfsserver>
sudo
exportfs /volume1/VM 10.0.1.0/24
VM ゲスト の移行を行いたい全てのホストにおいて、ボリュームへのアクセスを許可するためのプール定義を実施しなければなりません。ここでは NFS サーバのアドレスが 10.0.1.99 であり、 /volume1/VM
ディレクトリを /var/lib/libvirt/images/VM
ディレクトリにマウントするものとします。また、プール名は VM であるものとします。プールを定義するには、 VM.xml
ファイルを作成して下記のような内容を記述します:
<pool type='netfs'> <name>VM</name> <source> <host name='10.0.1.99'/> <dir path='/volume1/VM'/> <format type='auto'/> </source> <target> <path>/var/lib/libvirt/images/VM</path> <permissions> <mode>0755</mode> <owner>-1</owner> <group>-1</group> </permissions> </target> </pool>
あとは pool-define
コマンドを利用して libvirt
に読み込みます:
#
virsh pool-define VM.xml
このほかにも、プールの定義は virsh
コマンドで直接実施することもできます:
#
virsh pool-define-as VM --type netfs --source-host 10.0.1.99 \
--source-path /volume1/VM --target /var/lib/libvirt/images/VM
プール VM が作成されました
下記のコマンドは、 virsh
に何もパラメータを付与せずに実行した場合に起動される、 virsh
の対話型シェル内で実行した場合の例となります。あとはホストの起動時に自動的にプールを開始するように設定します (autostart オプションを指定します):
virsh #
pool-autostart VM
プール VM が自動起動としてマークされました
自動起動を無効化したい場合は、下記のように入力して実行します:
virsh #
pool-autostart VM --disable
プール VM の自動起動マークが解除されました
プールが存在しているかどうかを確認します:
virsh #
pool-list --all 名前 状態 自動起動 ------------------------------------------- default 動作中 はい (yes) VM 動作中 はい (yes)virsh #
pool-info VM 名前: VM UUID: 42efe1b3-7eaa-4e24-a06a-ba7c9ee29741 状態: 実行中 永続: はい (yes) 自動起動: はい (yes) 容量: 2,68 TiB 割り当て: 2,38 TiB 利用可能: 306,05 GiB
注意: VM ゲスト の移行を行う場合、移行元と移行先の両方で同じプールを定義しなければなりません。
プールを定義したら、次はディスクイメージを保持するボリュームを定義します:
virsh #
vol-create-as VM sled12.qcow2 8G --format qcow2
ボリューム sled12.qcow2 が作成されました
ここで設定したボリューム名は、 virt-install でゲストをインストールする際に使用します。
あとは virt-install
コマンドで openSUSE Leap の VM ゲスト を作成するだけです。 VM プールは --disk
オプションで指定しますが、移行時に --unsafe
オプションを指定しなくて済むようにするため、 cache=none を指定しておくことをお勧めします。
#
virt-install --connect qemu:///system --virt-type kvm --name \
sles15 --memory 1024 --disk vol=VM/sled12.qcow2,cache=none --cdrom \
/mnt/install/ISO/SLE-15-Server-DVD-x86_64-Build0327-Media1.iso --graphics \
vnc --os-variant sled15
インストールの開始中...
ドメインを作成中...
これで移行に関する全ての準備ができました。あとは現時点で VM ゲスト が動作している VM ホストサーバ で、移行先を指定して migrate
コマンドを実行するだけです。
virsh # migrate --live sled12 --verbose qemu+ssh://IP/ホスト名/system パスワード: Migration: [ 12 %]