KVMを使ったライブマイグレーション（前編）の続きになります。
⑥ライブマイグレーションを実行
最後にライブマイグレーションを実行します。
マイグレーションについては、調べたところ、
- 仮想マシンを実行させたままマイグレーションを行うライブマイグレーション
- 仮想マシンを停止した状態でマイグレーションを行うノンライブマイグレーション
という2つのマイグレーションがあることが分かりました。
マイグレーションの定義としては以下のような説明がございました。
移行は、ゲスト仮想マシンのメモリーと仮想デバイスの状態を移行先ホストの物理マシンに送信することで機能します。
https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/chap-KVM_live_migration#sect-KVM_live_migration-definition_and_benefits
仮想デバイスとは何なのか、上記記事でははっきりと記載がありませんでしたが、どうやら下記記事によると、CPUの状態も移行しているらしいです…よくわかりませんが、すごいことだけはわかりました…
https://qiita.com/haystacker/items/e94d8670086fb7c798bc
このマイグレーションですが、どのような時に使われるのか、マイグレーションの定義を引用させて頂いたRHELのドキュメントでは、以下のような場合に役立つと記載がございました。
- 負荷分散
ゲスト仮想マシンは、ホストマシンが過負荷になった場合、または別のホストマシンが十分に活用されていない場合に、使用率の低いホスト物理マシンに移動できます。
- ハードウェアの非依存性
ホストの物理マシンでハードウェアデバイスのアップグレード、追加、または削除が必要になった場合は、ゲスト仮想マシンを別のホストの物理マシンに安全に再配置できます。
- エネルギー節約
仮想マシンは他のホスト物理マシンに再配布できるため、アンロードしたホストシステムの電源を電力使用量の少ない時間帯に切ることで、節電やコスト削減が可能になります。
- 地理的な移行
仮想マシンは、待ち時間を短縮するため、または他の理由で必要な場合に、別の場所に移動できます。
私のイメージとしては、ある仮想マシンをホストしている物理サーバで障害があったあるいは起こりそう？だから緊急避難的にマイグレーションを使用する感じなのかなと思っていたのですが、今所有しているリソースを効率的に使用するために使うという側面もあるのだと気付きました。
では、最後に実際にライブマイグレーションを実践します。使用するコマンドは下記になります。
virsh migrate\
--live \ ライブ
--persistent \ #移行先ホストでのVM定義を永続化
--undefinesource \ #移行完了後、移行元ホストのVM定義を削除
--verbose \ #移行の進行状況を表示
migrate-test qemu+ssh://"移行先ホストのIPアドレス"/system
#qemu+sshは、リモートホストのVMを安全に管理するために使用する技術らしいです。
#/systemは、/system を追加することで、フルアクセス（root権限）が必要であることを （移行先ホストの？）libvirt に指示できるらしいです。
このコマンドですが、以下2つのエラーにより、うまく行きませんでした。
- 「error: Unable to resolve address '移行先ホスト名' service '49152': Name or service not known」
どうやら、virsh-migrateコマンドで移行先ホストのIPアドレスを指定しているだけではだめらしいです。
/etc/hostsに下記のように記述することで、エラーは出なくなりました。
"移行先ホストのIPアドレス" "移行先ホストのホスト名"
- 「error: internal error: QEMU unexpectedly closed the monitor (vm='移行対象VM名'): 日付 qemu-system-x86_64: Failed to put registers after init: Invalid argument」
これについて調べたところ、どうやら移行元と移行先ホストのCPU構成が一致していないことが原因で起こることが分かりました。
マイグレーションでは、CPUの状態も移行していることから、CPU構成が一致していないとうまくいかないのは確かに頷けるかなと思いつつ、解決方も調べてみました。
解決方法の1つとして、仮想マシンの詳細な設定が書かれたxmlファイルがあり、そこでCPUモデルを強制的に共通化する設定を加えるというものです。
virsh edit "vm名前"を行うと、editorが立ち上がり。xmlファイルが編集できる状態になります。そこに下記のような記述を追加しました。（元々のCPU設定は削除しております）
<cpu mode='custom' match='exact'>
<model fallback='allow'>qemu64</model>
<feature policy='disable' name='svm'/>
<feature policy='disable' name='vmx'/>
</cpu>
※実際の現場では、ホストのCPUが一致してない状態で上記のような設定を加えて、マイグレーション等を実行することは恐らくないと思いますので、参考程度にしてください。
上記の2つのエラーへの対応を行った上で再度実行しました。
そうしたところ、分かりにくいかもしれないが、移行元ホストでは元々あったmigrate-testというVMマシンは消えて、移行先ホストでrunning状態のmigrate-testが存在することが確認できました。
-
HostA（移行元ホスト）
-
HostB（移行先ホスト）
以上が、ライブマイグレーション実行までの流れとなります。
※⑤で仮想マシンを作成する際の--diskオプションでpoolではなく、ファイルパスを指定した場合
実は、--diskオプションで④で作成したストレージプールを指定する前に、vmディスクのファイルパスを指定して仮想マシンを作成する方法でライブマイグレーションを試していました（poolを指定する方法に気づいていませんでした）。
結果として、上記でもライブマイグレーションは実行できましたが、vmディスクが保存されているディレクトリの中身を見てみると、下記のように所有者や所有グループが違うため、よくわかっていませんが、libvirtが所有者なため、安全なのはpoolを指定する方なのかなと思いました。
最後に
ライブマイグレーションについて知らなかった部分が見えてきたことと、無事にライブマイグレーションができたので良かったです。ただ、本当に仮想マシンが稼働した状態で別ホストに移行しているのかといったところはまだまだ検証が足りない部分なので、機会があれば実施したいです。
ここまで見ていただきありがとうございます。もし記載事項に誤り等ございましたら、指摘いただけると幸いです。別のブログについても、これも機会があれば、作成しようと思います。
参考サイト
https://www.designet.co.jp/faq/term/?id=S1ZN
https://cloud.sakura.ad.jp/column/kvm/
https://www.redhat.com/ja/topics/virtualization/what-is-KVM
https://qiita.com/yoshiyasu1111/items/8d07a4fd55116fba07f7
https://dev.classmethod.jp/articles/how-to-install-and-configure-kvm-on-ubuntu2404/
https://qiita.com/ryutarom128/items/a31cc4e296442cd0f9d6
https://www.conversion.co.jp/tecblog/20241101/
https://qiita.com/ohtsuka-shota/items/78afa122e07ecaa3ad24
https://endy-tech.hatenablog.jp/entry/kvm_introduction
https://endy-tech.hatenablog.jp/entry/kvm_setup_and_libvirt_cli