VNC 有効時のライブマイグレーションの挙動に関して

[Hokuto Hoshi]

みなさま、

はじめまして。星と申します。

nova-compute におけるライブマイグレーションに関して質問させてください。

現在、以下の環境で Nova 環境の構築を行っております。
- 物理マシン8台、NIC は各2枚 (Global 側、Private 側にそれぞれ接続)
- Ubuntu 12.04 LTS
- nova-compute (Ubuntu package) 2012.1-0ubuntu2.2
- KVM
- インスタンス用ストレージは GlusterFS を使った共有ストレージ

この環境下で設定を行い、ライブマイグレーション以外の一通りの動作を確認することができました。
次にライブマイグレーションの動作確認を行いました。
# nova live-migration (instance-id) (destination)
上記コマンドは正常に成功したのですが、特に nova 側がエラーを吐くわけでもなく、マイグレーションが実行されない (正確には一瞬だけ
migrating に入ってすぐ戻る) 現象が起きました。
nova 側にログなどは残らず、nova-network がマイグレーション前のネットワーク設定をしているのが見えたくらいです。
libvirt 側には以下のように正常に接続できなかったようなエラーが残っていました。
2012-06-11 18:24:07.047+0000: 26961: error : qemuMonitorIORead:513 :
Unable to read from monitor: Connection reset by peer

LaunchPad のほうを見てみると、同じような現象の報告があったのですが、
https://bugs.launchpad.net/nova/+bug/1009974
nova.conf においてダブルクオートが正しくパースされない不具合に起因するようでした。
しかし、ここに記載されている通り、
VNC に関連する項目を nova.conf においてコメントアウトするとライブマイグレーションが正常に動作するようになりました。
設定ファイルを確認しましたが、ダブルクオートは nova.conf には存在していません。
この段階で、各インスタンスの VNC は各 Compute ノードのローカルアドレス (127.0.0.1) に bind されるようになりました。
virsh dumpxml した結果も、違いは VNC の IP アドレスのみという結果でした。

実際にライブマイグレーションを行った際、マイグレーション先のホストで tcpdump を取得したところ、
マイグレーション先には XML でインスタンスの情報が渡っているのが見えるのですが、その中に書かれている VNC の bind IP アドレスが
マイグレーション前のホストになっていました。
このアドレスがそのまま bind に使われてエラーとなっているのではないかな、と思っているのですが、
libvirt や nova のライブマイグレーションに関する挙動がよく理解できておらず詰まっている状態です。

nova.conf の上記関連の設定を貼りつけておきます。
この設定から VNC 関連の項目を削除すればライブマイグレーションは動作しています。

--
novncproxy_base_url=http://(controller's public ip):6080/vnc_auto.html
xvpvncproxy_base_url=http://(controller's public ip):6081/console
vncserver_proxyclient_address=192.168.100.3 (compute node's private ip)
vncserver_listen=192.168.100.3 (compute node's private ip)
vnc_keymap=ja

live_migration_uri=qemu+tcp://%s/system
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_TUNNELLED
--

どなたか、似たような症状、あるいは libvirt や nova の挙動として上記は既知の問題か、など
アドバイスいただけると幸いです。

以上、初投稿で長々と申し訳ありませんが何卒よろしくお願い致します。

--
Hokuto Hoshi
hok....@gmail.com

[Hideki Saito]

星さん

さいとうと申します。
ぼくの手元でも現象が再現しました。

> 実際にライブマイグレーションを行った際、マイグレーション先のホストで tcpdump を取得したところ、
> マイグレーション先には XML でインスタンスの情報が渡っているのが見えるのですが、その中に書かれている VNC の bind IP アドレスが
> マイグレーション前のホストになっていました。
> このアドレスがそのまま bind に使われてエラーとなっているのではないかな、と思っているのですが、
> libvirt や nova のライブマイグレーションに関する挙動がよく理解できておらず詰まっている状態です。

ご指摘の通りだと思います。
ぼくは、ワークアラウンドとして、

> vncserver_listen=192.168.100.3 (compute node's private ip)

のIPアドレス設定を、

vncserver_listen=0.0.0.0

として逃げてしまいました。
この設定であれば、問題なくlive-migrationは動作しています。
ただし、このままでは *:5900 でbindしていまうので、何らかの形で
適切なフィルタは必要になるかと思います。


2012年6月12日 4:15 Hokuto Hoshi <hok....@gmail.com>:

[Hokuto Hoshi]

みなさま、

星です。
間違えて余計な情報がついた署名で post してしまったため、google groups のオンラインアーカイブから当該 post を削除させていただきました。
念のため先ほどお送りした本文に返信する形でお知らせさせていただきます。
申し訳ありませんでした。以後気をつけます。。。

2012年6月13日 3:41 Hokuto Hoshi <hok....@gmail.com>:
> さいとうさん、
>
> 星です。
>
> ご返信いただきありがとうございます。
> 再現性のある問題のようで少し安心しました。
>
> 確かに、0.0.0.0 としてしまえば bind できますね。
> こちらの環境でも動作を確認できました。ありがとうございます。
> public 側インタフェースから直接 VNC コンソールにアクセスできてしまうのもよくないので、
> ひとまず、上流の FW で制御しておくことにしました。
>
> LaunchPad 上ではダブルクオート問題としてドキュメントの修正が進んでいるようです。
> 今回の件については設定の問題ではない気がするので、伝わるか不安なもののコメントを追記してみました。
>
> 2012年6月12日 21:20 Hideki Saito <s...@fgrep.org>:

> --
> Hokuto Hoshi
> hok....@gmail.com

--
Hokuto Hoshi
hok....@gmail.com