LiveMigrationの失敗を手動復旧する

nova live-migration に何らかの理由で失敗して、StatusがMIGRATINGのままnovaから見るとダンマリになってしまうようなことが、OpenStackでは時々あります。
※実際にVMインスタンスは正常に稼働している状態を想定しています。
原因にはいろいろありますが、このような状態になった時にVMの状態を復旧させる方法を書いておきます。

■ StatusはMIGRATINGのまま...

StatusがMIGRATINGのままでも、VMインスタンス自体は起動中でサービスも提供できている状態だとすると、novaの構成管理DBの状態だけを修正すれば、nova live-migrationコマンド発行前のキレイな状態に戻せるハズです。

$ nova list
+--------------------------------------+------+-----------+---------------------+
| ID                                   | Name | Status    | Networks            |
+--------------------------------------+------+-----------+---------------------+
| bfd70cf1-5caf-4bda-8ea1-9a4d25dd4cd4 | vm00 | ACTIVE    | network00=10.0.0.12 |
| e2e8d400-d590-4d18-8333-dc699ef85325 | vm01 | MIGRATING | network00=10.0.0.13 |
+--------------------------------------+------+-----------+---------------------+

■ 該当VMインスタンスのステータスを確認してみます

確認に必要なフィールドとしてはuuid,hostname,host,task_stateがあれば問題なさそうです。

mysql> select uuid,hostname,host,task_state from instances where uuid='e2e8d400\
-d590-4d18-8333-dc699ef85325';
+--------------------------------------+----------+----------+------------+
| uuid                                 | hostname | host     | task_state |
+--------------------------------------+----------+----------+------------+
| e2e8d400-d590-4d18-8333-dc699ef85325 | vm01     | ec0n0704 | migrating  |
+--------------------------------------+----------+----------+------------+
1 row in set (0.00 sec)
□ task_stateを更新してみる

task_stateをNULLにしてしまえばOKみたいです

mysql> update instances set task_state=NULL where uuid='e2e8d400-d590-4d18-8333\
-dc699ef85325';
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0
□ 確認

うまくいったようです...それでは構成管理DBで確認してみます。

mysql> select uuid,hostname,host,task_state from instances where uuid='e2e8d400\
-d590-4d18-8333-dc699ef85325';
+--------------------------------------+----------+----------+------------+
| uuid                                 | hostname | host     | task_state |
+--------------------------------------+----------+----------+------------+
| e2e8d400-d590-4d18-8333-dc699ef85325 | vm01     | ec0n0704 | NULL       |
+--------------------------------------+----------+----------+------------+

nova list でも確認してみます。

$ nova list
+--------------------------------------+------+--------+---------------------+
| ID                                   | Name | Status | Networks            |
+--------------------------------------+------+--------+---------------------+
| bfd70cf1-5caf-4bda-8ea1-9a4d25dd4cd4 | vm00 | ACTIVE | network00=10.0.0.12 |
| e2e8d400-d590-4d18-8333-dc699ef85325 | vm01 | ACTIVE | network00=10.0.0.13 |
+--------------------------------------+------+--------+---------------------+

構成管理DBとしても正常にもどりました。
もちろんVMインスタンスとしては元々正常に稼働していたので、これで名実ともに復旧したというわけですね。