OpenStack Juno Live-对于高负载和大小大于64 and的实例，迁移永远不会完成
OpenStack Juno Live-对于高负载和大小大于64 and的实例，迁移永远不会完成
提问于 2016-05-13 17:53:54
我遇到过这样的情况，即活迁移似乎永远不会完成或出错。
以下是我如何能够重现这个问题。
下面是我正在迁移的实例：
[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。目前是2016年5月13日(星期五)17:13时46分，现场迁徙仍在进行中。一旦我消除了实例上的“压力”，它就会成功地完成。
在生产环境中，我有由于某种原因正在运行的实例，我希望通过消除那些导致高负载的应用程序，在不导致应用程序中断的情况下实时迁移它们。
是否有一些配置项，我可以在不首先减少实例负载的情况下使用它来迁移实例？
更新:我有什么版本的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最新情况二：
我只想确保正确地发出virsh命令：
在我的VM所在的计算节点上。我展示了qemu的一个很好的版本：
[root@osc1-net-002 ~]# qemu-io --version
qemu-io version 2.1.2现在，我做了一个virsh list来获取我想要生存的VM的实例名称，迁移如下：
[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命令看上去没问题。谢谢迈克尔！
正如我上面提到的，我已经发布了实时迁移，我在/etc/nova/nova-compute.log on 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，这使我认为如果我的VM是节流的，那么它的节流不够。
最新情况四：
我成功地移植了一个负载很重的VM。在正在迁移的计算服务器上，我执行了以下操作：
[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 |
...VM的挂起似乎不影响在VM上运行的任何进程。也许我只是看得不够仔细。
然后，我在命运计算服务器上运行了以下命令：
[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
Server Fault用户
发布于 2016-05-14 03:23:21
由于过于繁忙的VM而导致迁移失败已被认为是一个问题。不幸的是，虽然qemu提供了一个解决方案，但它并不是通过libvirt公开的，因此OpenStack无法使用它。
Qemu的解称为自收敛.。这意味着，如果VM太忙，以至于预测迁移永远不会完成，那么VM的执行就会受到限制，从而可能允许迁移完成。
自动收敛从QEMU1.6继续提供，它应该在您的OpenStack Juno安装中出现.在这个版本中，节流量是固定的。由于qemu 2.5 (此时它是全新的，而且您还没有)，节流是动态的，如果VM繁忙，它可以动态地在任何地方进行节流，但只需尽可能多地允许迁移完成。
因为这个监视器命令没有在libvirt中公开，所以OpenStack无法利用它。目前，您必须手动将自动收敛应用于运行中的VM。例如，以root身份登录到当前正在运行VM的计算节点并执行：
virsh qemu-monitor-command instance-000007e1 --hmp migrate_set_capability auto-converge on如果成功，则不应输出任何内容，并返回0。然后，您可以开始迁移。
在QEMU2.5中，您可以使用监视命令migrate_set_parameter x-cpu-throttle-initial ##和migrate_set_parameter x-cpu-throttle-increment ##来调优动态节流，这两个命令分别设置了初始节流百分比，以及在迁移仍未完成时使用的附加节流增量。
希望这些最终将被添加到libvirt中，以便未来版本的OpenStack能够直接管理这一点。
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://serverfault.com/questions/776662
复制相关文章
相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号