我遇到了实时迁移似乎没有完成或错误的情况。
这是我如何能够重现这个问题。
这是我正在迁移的实例：
[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是我创build的，看起来像这样：
[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
…在5月12日20:10:41 GMT 2016.现在是5月13日星期五17:13:46 GMT 2016和实时迁移仍在继续。 一旦我杀死了实例的“压力”，它就会成功完成。
在生产环境中，由于某种原因，我有实例正在热运行，我希望通过closures导致高负载的应用程序来实时迁移它们而不导致应用程序中断。
有没有一些configuration项我可以tweek或一些virsh技巧我可以用来迁移实例没有先减less实例的负载？
更新：我有什么版本的Qemu？
谢谢你一个很好的答案迈克尔。 我想弄清楚我有什么版本的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
更新II：
我只是想确保我正确地发出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。 迈克尔回到我身边，证实virsh命令看起来没问题。 感谢迈克尔！
如上所述，我已经发布了实时迁移，我在osc1-net-002的/etc/nova/nova-compute.log看到了这一点：
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的bytes processed=2525969442377大于total=75515105280 ，这让我觉得如果我的虚拟机被扼杀，它不会被扼杀。
更新IV：
我能够成功实时迁移出现重负载的虚拟机。 在计算服务器上，我正在迁移从我执行的：
[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 | ...
虚拟机挂起似乎不会干扰在虚拟机上运行的任何进程。 也许我只是不够努力。
然后在destentation计算服务器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
由于虚拟机过于繁忙导致迁移失败已被认为是一个问题。 不幸的是，虽然qemu提供了一个解决scheme，但它不会通过libvirt API暴露，因此OpenStack无法使用。
Qemu的解决scheme被称为自动收敛 。 这意味着，如果一个虚拟机如此繁忙以至于迁移被预测为永远不会完成，则虚拟机的执行将被限制，从而可能允许迁移完成。
自动收敛可以从qemu 1.6以上版本获得，它应该存在于您的OpenStack Juno安装中。 在这个版本中，节stream量是固定的。 由于qemu 2.5（现在是全新的，你不会有这个），节stream是dynamic的，如果VM很忙，它可以dynamic调整到99％，但只要允许迁移完成。
由于这个监视器命令没有暴露在libvirt API中，所以OpenStack不能利用它。 目前，您将不得不手动应用自动收敛到正在运行的虚拟机。 例如，以root身份login到当前正在运行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 ##来调整dynamic限制migrate_set_parameter x-cpu-throttle-increment ##其中设置初始限制百分比以及将使用的附加限制的增量迁移仍然不会完成，分别。
希望这些最终将被添加到libvirt API，以便将来的OpenStack版本可以直接pipe理这个。