我遇到过实时迁移似乎永远无法完成或者出错的情况。
以下是我重现该问题的方法。
这是我正在迁移的实例：
[root@osc1-mgmt-001 tmp]# nova show gb72-net-002-org-001
+--------------------------------------+---------------------------------------------------------------------+
| Property | Value |
+--------------------------------------+---------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | osc1-net-002.example.com |
| OS-EXT-SRV-ATTR:hypervisor_hostname | osc1-net-002.example.com |
| OS-EXT-SRV-ATTR:instance_name | gb72-net-002-org-001 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | migrating |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2016-05-12T20:01:23.000000 |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| config_drive | |
| created | 2016-05-12T20:00:58Z |
| flavor | gb72_vm (668ca3b4-a7c0-4309-a11e-4fb5377e4180) |
| hostId | 44206a2390a038b0ede2a4375f1239b0cef917149bd5976fcada6781 |
| id | 3b176ee2-fcf3-41a6-b658-361ffd19639e |
| image | CentOS-7-x86_64-GenericCloud (588e035d-2e1e-4720-94c4-8b000bf9d2ef) |
| key_name | nk |
| metadata | {} |
| name | gb72-net-002-org-001 |
| os-extended-volumes:volumes_attached | [{"id": "16afe52c-31b0-4a3a-b718-aa1789df2852"}] |
| public-47 network | 10.29.105.13 |
| security_groups | default |
| status | MIGRATING |
| tenant_id | 9d011b7c8d104af1b887e229cee436d2 |
| updated | 2016-05-13T17:07:48Z |
| user_id | fa8b956c89304124967bb4bcea54124b |
+--------------------------------------+---------------------------------------------------------------------+
这个口味gb72_vm是我创造的，看起来像这样：
[root@osc1-mgmt-001 tmp]# nova flavor-show gb72_vm
+----------------------------+--------------------------------------+
| Property | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 20 |
| extra_specs | {} |
| id | 668ca3b4-a7c0-4309-a11e-4fb5377e4180 |
| name | gb72_vm |
| os-flavor-access:is_public | True |
| ram | 72000 |
| rxtx_factor | 1.0 |
| swap | 16000 |
| vcpus | 8 |
+----------------------------+--------------------------------------+
启动我安装的实例后stress，我对实例进行压力如下：
[centos@gb72-net-002-org-001 stress-1.0.4]$ stress -c 6 -m 4 --vm-bytes 512M
我也在该实例上运行top，它看起来像这样：
top - 17:17:02 up 21:15, 1 user, load average: 10.11, 10.08, 10.06
Tasks: 149 total, 12 running, 137 sleeping, 0 stopped, 0 zombie
%Cpu(s): 62.0 us, 38.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 72323392 total, 70503632 free, 1344768 used, 474988 buff/cache
KiB Swap: 16383996 total, 16383996 free, 0 used. 70740048 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10273 centos 20 0 7260 96 0 R 86.7 0.0 1008:21 stress
10276 centos 20 0 7260 96 0 R 84.7 0.0 1008:22 stress
10271 centos 20 0 7260 96 0 R 84.1 0.0 1008:00 stress
10275 centos 20 0 7260 96 0 R 82.1 0.0 1009:28 stress
10270 centos 20 0 531552 218716 176 R 80.7 0.3 1011:42 stress
10272 centos 20 0 531552 142940 176 R 80.4 0.2 1012:40 stress
10269 centos 20 0 7260 96 0 R 78.7 0.0 1008:38 stress
10274 centos 20 0 531552 333404 176 R 73.1 0.5 1012:32 stress
10267 centos 20 0 7260 96 0 R 70.4 0.0 1008:41 stress
10268 centos 20 0 531552 38452 176 R 65.8 0.1 1011:29 stress
1 root 20 0 191352 6652 3908 S 0.0 0.0 0:06.00 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.45 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.12 kworker/u16:0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.62 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/0
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/1
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/2
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/3
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/4
14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/5
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/6
16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcuob/7
17 root 20 0 0 0 0 R 0.0 0.0 0:02.42 rcu_sched
18 root 20 0 0 0 0 S 0.0 0.0 0:00.44 rcuos/0
19 root 20 0 0 0 0 S 0.0 0.0 0:00.29 rcuos/1
20 root 20 0 0 0 0 S 0.0 0.0 0:00.32 rcuos/2
我发出了命令……
# nova live-migration gb72-net-002-org-001 osc6-net-001.example.com
... 2016 年 5 月 12 日 20:10:41 GMT。目前是 2016 年 5 月 13 日星期五 17:13:46 GMT，实时迁移仍在进行中。只要我关闭实例上的“stress”，迁移就会成功完成。
在生产环境中，我有一些实例由于某种原因而运行繁忙，我想通过关闭那些造成高负载的应用程序来实时迁移它们，而不会导致应用程序中断。
是否有一些我可以调整的配置项或一些 virsh 技巧可以用来迁移实例，而无需首先减少实例的负载？
更新：我有哪个版本的 Qemu？
非常感谢 Michael 的精彩回答。我正在尝试弄清楚我拥有的 qemu 版本：
# rpm -qa | grep qemu
ipxe-roms-qemu-20130517-8.gitc4bce43.el7_2.1.noarch
libvirt-daemon-driver-qemu-1.2.17-13.el7_2.3.x86_64
qemu-img-rhev-2.1.2-23.el7_1.4.x86_64
qemu-kvm-common-rhev-2.1.2-23.el7_1.4.x86_64
qemu-kvm-rhev-2.1.2-23.el7_1.4.x86_64
[root@osc1-net-002 ~]# virsh -v
1.2.17
更新二：
我只是想确保我virsh正确发出了命令：
在我的虚拟机所在的计算节点上。我显示我有一个好的 qemu 版本：
[root@osc1-net-002 ~]# qemu-io --version
qemu-io version 2.1.2
现在我要virsh list获取我想要实时迁移的虚拟机的实例名称，如下所示：
[root@osc1-net-002 ~]# virsh list
Id Name State
----------------------------------------------------
50 gb72-net-002-org-001 running
因此基于此，我将在我的计算服务器 ocs1-net-002 上执行此命令来限制gb72-net-002-org-002：
[root@osc1-net-002 ~]# virsh qemu-monitor-command gb72-net-002-org-002 --hmp migrate_set_capability auto-converge on
然后我可以尝试像这样执行实时迁移：
[root@osc1-mgmt-001 ~]# nova live-migration gb72-net-002-org-002 osc6-net-001.example.com
这是要发出的正确命令集吗？
更新 III。Michael 回复了我并确认virsh命令没有问题。谢谢 Michael！
正如我上面提到的，我遇到了实时迁移问题，并且看到了以下/etc/nova/nova-compute.log情况osc1-net-002：
DEBUG nova.virt.libvirt.driver [-] [instance: bf616c8b-0054-47ee-a547-42c2a946be2e] Migration running for 2405 secs, memory 2% remaining; (bytes processed=2520487990540, remaining=1604055040, total=75515105280) _live_migration_monitor /usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py:5721
我注意到实时迁移已经运行了 40 分钟。此外，bytes processed=2525969442377大于，total=75515105280这让我认为，如果我的虚拟机受到限制，那么限制还不够。
更新四：
我成功实时迁移了一台负载过重的虚拟机。在要迁移的计算服务器上，我执行了以下操作：
[root@osc1-net-002 ~]# virsh qemu-monitor-command gb72-net-002-org-001 -hmp stop
error: Timed out during operation: cannot acquire state change lock (held by remoteDispatchDomainMigratePerform3)
[root@osc1-net-002 ~]# virsh suspend gb72-net-002-org-001
Domain gb72-net-002-org-001 suspended
我不确定为什么会出现这个错误，但这似乎并不重要。
现在我检查实时迁移是否已完成：
[root@osc1-net-002 ~]# nova list
+--------------------------------------+----------------------+--------+------------+-------------+-----------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+----------------------+--------+------------+-------------+-----------------------+
| de335b04-8632-48e3-b17c-d80ac2d02983 | gb72-net-002-org-001 | ACTIVE | - | Running | public-47=10.29.105.9 |
| 229d8775-3a3c-46a6-8f40-7f86ca99af88 | test-net-001-org | ACTIVE | - | Running | public-47=10.29.105.4 |
| 6d2ddad3-3851-4495-bf14-b787fed2ad99 | test-net-001-org-2 | ACTIVE | - | Running | public-47=10.29.105.7 |
+--------------------------------------+----------------------+--------+------------+-------------+-----------------------+
[root@osc1-net-002 ~]# nova show gb72-net-002-org-001
+--------------------------------------+---------------------------------------------------------------------+
| Property | Value |
+--------------------------------------+---------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | osc6-net-001.example.com |
| OS-EXT-SRV-ATTR:hypervisor_hostname | osc6-net-001.example.com |
| OS-EXT-SRV-ATTR:instance_name | gb72-net-002-org-001 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
...
虚拟机暂停似乎不会干扰虚拟机上运行的任何进程。也许我只是没有仔细观察。
然后在目标计算服务器 osc6-net-001.example.com 上执行了以下命令：
[root@osc6-net-001 ~]# virsh qemu-monitor-command --hmp gb72-net-002-org-001 cont
[root@osc6-net-001 ~]# virsh resume gb72-net-002-org-001
Domain gb72-net-002-org-001 resumed
答案1
由于虚拟机太忙而导致迁移失败已被视为一个问题。不幸的是，虽然 qemu 提供了解决方案，但它并未通过 libvirt API 公开，因此 OpenStack 无法使用。
Qemu 的解决方案称为自动收敛。这意味着，如果虚拟机太忙以至于预计迁移永远无法完成，则虚拟机的执行将受到限制，以便可能允许迁移完成。
自动融合功能从 qemu 1.6 开始可用，它应该存在于您的 OpenStack Juno 安装中。在此版本中，节流量是固定的。从 qemu 2.5（此时是全新的，您还无法使用它）开始，节流是动态的，如果 VM 繁忙，它可以被动态节流高达 99%，但仅限于允许迁移完成所需的程度。
由于此监控命令未在 libvirt API 中公开，因此 OpenStack 无法利用它。目前，您必须手动将自动聚合应用于正在运行的 VM。例如，以 root 身份登录到当前正在运行 VM 的计算节点并执行：
virsh qemu-monitor-command instance-000007e1 --hmp migrate_set_capability auto-converge on
如果成功，则不会输出任何内容并返回 0。然后您就可以开始迁移了。
在 qemu 2.5 中，您可以使用监视命令调整动态节流migrate_set_parameter x-cpu-throttle-initial ##，并migrate_set_parameter x-cpu-throttle-increment ##分别设置初始节流百分比以及在迁移仍无法完成时使用的额外节流增量。
希望这些最终能够被添加到 libvirt API 中，以便未来版本的 OpenStack 可以直接管理它。