KVM on SUSE15(SLE/openSUSE Leap) virt-manager でライブマイグレーション

　長い事 SUSE Linux をやっていると、 YaST GUI にあまりにも慣れすぎてしまって、すっかりキーボードをたたく事に億劫になってしまいます。Linux やってるエンジニアがキーボードにこだわるのはわかりますが、私は SUSE Linux 使う上ではマウスにこだわるヒトになってしまいました。

良くテレビドラマやニュースの資料映像なんかで、ブラインドタッチがやたらと早くて、マウスなんて全然つかってないじゃないか、という資料映像みたいなシーンを見ますが、私にはわかる。

「嘘だ、演技だ」

特に「ハケンの品格２」の篠原涼子のキーボード叩く演技は下手だったなぁ。ブラインドタッチになってない。ただ指がキーボードの上を撫ぜてるだけで「スーパー派遣」の品格がなかった。下手なビデオのオフィスシーンの方が演技している場合があるンですよ。

逆にマウスを使いこなしているシーンを見ると「演技っぽくなくリアル」に思えてくるものです。

それくらいいまの時代、マウスは重要です。

まぁ与太はそこまでにして

ー virt-manager GUI で KVM ゲストのライブマイグレーション

というのが今回のテーマです。

随分と昔に XEN 環境＋ iSCSI NAS を使ったライブマイグレーションをやた事を思い出します。

iSCSI 上に仮想イメージを導入し、ついでに Live Migration してみる

https://islandcnt.exblog.jp/19941486/

時は移り変わり、まず XEN は見なくなったし SUSE でも XEN から KVM への移行ガイドを用意するくらい、仮想化と言えばすっかり KVM の時代になってしまいました。

かわいそうな Citrix ....

今回は SUSE Linux Enterprise 15.0 と openSUSE Leap 15.2(gnome) 上で KVM が稼働しているので、それぞれライブマイグレーションしてみました。virsh migrate --live .... コマンドではなく、 virt-manager、 GUI を使います。

※ SLE 側は gnome Desktop のみです。openSUSE Leap 側も gnome Desktop を使っています。

ー リモート virt-manager に接続

openSUSE Leap 15.2 側の X 端末から Virtual Machine Manager GUI. を起動して、別なハイパーバイザー(SLES15 KVM)側に接続します。

# virt-manager &

openSUSE より File > Add Connection から、SLES の KVM ハイパーバイザーにログインします。そうするとエラー。

openssh-askpass パッケージが要求されます。

yast を見ると ssh-askpass は既にインストールされていますが、ssh-askpass-gnome はインストールされていないため、追加インストールします。

openSUSE Leap 16.2 では標準リポジトリに openssh-askpass, openssh-askpass-gnome が標準で含まれているため、zypper か YaST でインストールするだけです。

接続先のパスワードが要求されました。

リモートハイパーバイザーに接続できました。

稼働中のVMをポイントして右ボタンから Migrate をします。

今回はネットワーク上の共有ストレージ（iSCSI や NFS）を使っていない（単にイメージをSCP コピーしただけの手抜き）ので、エラーとなりました。Advanced Option の中に Allow unsafe のチェックボックスがあるのでこれをチェックして、強引にマイグレートしてみます。(敗因)

無事、SLE のインスタンスを openSUSE Leap 側に移行出来ました。

ー よくあるトラブル

よくあるトラブルとして、移行元、移行先のディレクトリ構造が違ったり、移行先に、仮想イメージがマウントしているインストールDVDメディアがないなどが原因で移行出来ないトラブルがあります。使わないハードウェアは外しておきます。VM のコールドブートが必要ですけど...

ー 頻繁に認証を求められる

リモートハイパーバイザーにアクセスすると、頻繁に root パスワードを求めてきました。原因／意味不明です。ちょっと実用的ではないですね。(敗因)

ー SLE の場合

SUSE Linux enterprise (SLES) 15 の場合、openssh-askpass, openssh-askpass-gnome は標準リポジトリに含まれないため、software.opensuse.org より１クリックインストールするか、expert Download にある指示に従って、リポジトリの追加、インストール

します。

openssh-askpass-gnome

https://software.opensuse.org/package/openssh-askpass-gnome

openssh-askpass

https://software.opensuse.org/package/openssh-askpass

zypper addrepo https://download.opensuse.org/repositories/openSUSE:Leap:15.2:Update/standard/openSUSE:Leap:15.2:Update.repo

zypper refresh

zypper install openssh-askpass-gnome

zypper addrepo https://download.opensuse.org/repositories/openSUSE:Backports:SLE-15-SP3/standard/openSUSE:Backports:SLE-15-SP3.repo

zypper refresh

zypper install openssh-askpass

zypper でインストールできない場合は YaST のソフトウェア管理 (YaST Software Management) でインストールできました。

opensuse152:~ # rpm -qa openssh*

openssh-askpass-1.2.4.1-bp153.1.3.x86_64

openssh-askpass-gnome-7.6p1-7.13.x86_64

openssh-helpers-7.6p1-7.8.x86_64

openssh-7.6p1-7.8.x86_64

opensuse152:~ #

今度は openSUSE Leap に移動した、VM インスタンスを SLE 側に戻しました。

よくあるトラブル

ー 移行先のメモリが足りない

　

　メモリアロケーションエラーになります。メインで使っているハイパーバイザーの稼働率が高く、８割程度でパツンパツンのところに、無理してマイグレートしないことです。不要不急のVMインスタンスをシャットダウンして、移行させるとうまく移行できます。

そもそもライブマイグレートは負荷の高い、ミッションクリティカルなサービスを移動させるのが本質的な目標なので、インスタンスを止めるのは本末転倒かもです。

ー 必ずネットワークの共有ディスクを使うこと、バックアップは重要

　今回は手抜きして、 QEMU のイメージと XML ファイルを SCP コピーして、マイグレートしましたが、できたできたと喜んでマイグレートしてたら、遂にブートローダーが壊れて起動できなくなりました。まぁ今回はテスト環境で、スレーブ用DNSサーバーだったので笑って済ませますが、本番環境がこの様な事では済まされません。

必ずバックアップを取って、共有ディスクからマイグレートします。

ー 異なる環境ではマイグレートできない

インスタンスのイメージがあるディレクトリなど環境は必ず揃えること。特に、インスタンスを作ったときのインストールDVDメディアは、仮想ハードウェアから削除しておくことです。

ー ２つのハードウェアの違いはあるか

　ライブマイグレーションの大きな課題としては、双方のハードウェアアキテクチャに大きな違いがあってはいけないことです。一度 XEN 時代にテストしたのですが、AMD アキテクチャから Intel マシンの移行は、コールド移行もできませんでした。同じ Intel 系でも、CPU世代が大きく違ったりする場合のライブマイグレーションがどの程度成功するかは未知数です。どれだけ環境が異なると移行できないかは経験を積むしかないでしょう。

また移行先のハイパバイザーが古かったりOSベンダーが異なると、成功の可能性は低そうです。

例えば、最新の XEON プロセッサ搭載サーバーから、数年前の古い Core i3 の古いデスクトップ応用PCへの移行がうまく行くとは思えません。コールドマイグレーションでさえ失敗しそうです。逆のケースではうまくいきそうなきがします。（ ...そう思っているだけですが… ）

いずれにせよ、いざと言う時にライブマイグレーションがおこなえるかどうか、システムを止められる機会に、計画的にテストしておく事が重要です。

ー まとめ

ライブマイグレーションは万能の機能ではありません。想定していなかった設定ミスで失敗したり、

起動できなくなるというトラブルもありました。個人的にはサービス停止が、１０分許されるなら、イメージの別 HV へのコピー、サービス 再起動でいい。仮想化マイグレーションは、運用技術としては自己満足に陥りやすい危険性があります。

ただし、せっかくハイパーバイザー運用するつもりなら、キチンと iSCSI などの共有ストレージを作って２つ以上の HV 運用を検討すべきでしょう。いざという時に提供される手段だし、緊急時のオペレーションテスト、訓練も重要です。

また、「小＞大」、「古＞新」のマイグレーションは成功の可能性が高いのでしょうが、新しいサーバーから古いハイパーバイザーハードウェアへの移行はかなり不安があります。いずれにせよ行き当たりばったりのチャレンジは避けた方がよさそうです。

今回は、SUSE Linux15(SLE/openSUSE Leap) で GUI からライブマイグレーションをテストしてみました。実用性、可用性はギリギリ合格点。 実運用には Open stack などを検討すべきでしょう。

また、SLE ではなく openSUSE Leap 15.2 をつかってみた初めての KVM ですが、使用感は SLES とそれほど変わらないので、ミッションクリティカルではないシーンでは openSUSE Leap でも充分かなと感じました。

isLandcenter.jp