基于OpenStack的虚拟机在线迁移-报错解决

本文分享了一种采用计算存储松耦合结构的虚拟机在线迁移方法,实现了高速迁移,最短仅需6秒。文章详细介绍了迁移配置流程,包括Nova.conf、libvirtd.conf等关键文件的修改,以及在迁移过程中遇到的问题与解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一直想和大家分享虚拟机的在线迁移,考虑到稳定性,我们在线上运行了几个月比较稳定后,再总结出来和大家分享。

大致描述一下场景:系统采用了计算存储松耦合结构,虚机的映像文件在远端共享存储上,所以迁移起来速度很快。在我们系统中,最快一个用了6秒,即完成了在线迁移,这是真正的live migration,我们一边迁移,一边故意在虚机里写数据,也正常完成。

配置方案

1.修改Nova.conf文件

添加:
image_cache_manager_interval=0
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE
修改:
vncserver_listen=0.0.0.0

2.参与的计算节点机器名字都能ping通。

3.修改计算节点上 /etc/libvirt/libvirtd.conf:

before : #listen_tls = 0
after : listen_tls = 0
before : #listen_tcp = 1
after : listen_tcp = 1
add: auth_tcp = "none"

4.修改 /etc/sysconfig/libvirtd:

before :# LIBVIRTD_ARGS="--listen"
after:LIBVIRTD_ARGS="–listen"

5.在源计算节点上修改要迁移虚机的/var/run/libvirt/qemu/instance–xxx.xml文件,删除migrate-qemu-fd这一行,将vnc参数修改成0.0.0.0

6.重启计算节点上nova

7备注:

1.由于云机之前没有配置在线迁移,在迁移虚机之前,需要重启虚机。
2..因为计算节点上libvirtd的配置中增加了auth_tcp="none",算是一个安全漏洞,需要寻找更安全的办法,或者在迁移完成之后,注释掉这行,重启libvirt
3已经编写了一个辅助程序自动做迁移

遇到的问题和解决办法

1.虚机的disk 的cache mode为writethrough,迁移的时候报错

OpenStack认为在centos上磁盘cache mod为writethrough时,迁移是不安全的。
解决的办法 :在nova.conf live_migration_flag参数后面增加VIR_MIGRATE_UNSAFE,官方在线迁移配置文件里没有这个参数。

2.qemu1.4的一个bug导致迁移失败

迁移失败,在目的节点上/var/log/libvrit/qemu/instances--xxxx.log里:
char device redirected to /dev/pts/1 (label charserial1)
qemu: warning: error while loading state section id 2
load of migration failed
解决办法:
1.在源计算节点上修改要迁移虚机的/var/run/libvirt/qemu/instance–xxx.xml文中删除migrate-qemu-fd这一行
2.重启源计算节点上的libvirtd
3.然后再执行nova live-migration命令
这个操作已经编写了一个程序自动执行。

3.vncserver的问题,需要重启虚拟机才可以迁移。

由于之前Nova.conf中vncserver_listen=计算机节点的ip,所以在虚拟机Kvm进程中参数中vnc=计算节点的ip,迁移的时候报错,在目的节点绑定不了源节点的IP,所以需要修改Libvirt.xml配置文件,重启虚机,然后才能进行迁移。
解决办法:
1.在源计算节点上/var/run/libvirt/qemu/instance–xxx.xml文中将vnc的参数修改成0.0.0.0
2.重启源计算节点libvirtd
3.然后再执行nova live-migration命令
这个操作已经编写了程序来自动完成

4.迁移完成后console.log,disk属主变成了root/root

迁移完成后,发现虚机的console.log和disk文件属主由qemu.qumu变成了root.root,这个估计是OpenStack迁移程序的问题,这个问题目前没有影响虚机。
解决办法:
修改文件属主,这个操作已经编写了程序来自动完成

5.源节点和目的节点cpu不兼容问题

迁移失败,在/var/log/nova/compute的日志:
"InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.\n\n0\n\nRefer to
解决办法:
目前还没有解决办法

6.目的节点内存为负,

迁移失败,从控制节点的api.log上输出的错误是目的节点内存为-3400,不能满足迁移的需要。
解决办法:
用nova命令指定在该计算节点上创建虚机,能够成功。估计是迁移时候的调度 算法和创建虚机时的调度算法不一致。

7.错误日志,在2.4上api.log

迁移时候一般看的日志有:
1.目的节点上的/var/log/libvirt/qemu/instances–xxx.log
2.目的节点上的/var/log/nova/compute.log
3.源节点上的/var/log/nova/compute.log
有时候迁移失败,命令行执行后报错:
ERROR: Live migration of instance bd785968-72f6-4f70-a066-b22b63821c3b to host compute-13 failed (HTTP 400) (Request-ID: req-180d27b5-9dc7-484f-9d9a-f34cccd6daa2)
但在上述的三个日志文件中都看不到任何的错误信息。
解决办法:
在控制节点或者是在操作迁移命令的节点上/var/log/nova/api.log有错误信息

走的弯路

1.尝试不用修改nova.conf里的vncserver_listen参数为0.0.0.0,

将/var/run/log/libvirt/qemu/instances--xxx.log里的vnc改成目的节点的ip,重启libvritd,然后进行迁移,可以成功,但如果迁移失败,当需要重新虚机的时候,虚机启动失败,在/var/log/libvrit/qemu/instances-xx.log的错误是
Failed to start VNC server on `172.18.2.15:0': Failed to bind socket: Cannot assign requested address
而/mnt/instances/instance--xxx/libvirt.xml里没有修改成目的节点的Ip。不知道这个参数被保存到了哪里

2.vnc 端口问题

在一次迁移失败后,在目的节点/var/log/libvirt/qemu/instance--xxx.log里的错误是:
2013-11-05 05:42:39.401+0000: shutting down
qemu: terminating on signal 15 from pid 10271,
猜想是由于虚机在源节点上的vnc监听端口在目的节点上被占用,所以导致启动不了。后来在其他机器上做了测试发现,在迁移到目的节点后vnc的端口自己会调整。
### OpenStack迁移报错的原因分析与解决方案 #### 一、错误原因 OpenStack迁移过程中可能出现多种类型的错误,这些错误通常涉及计算节点之间的资源协调以及底层硬件兼容性等问题。以下是常见的几种可能引发冷迁移失败的情况及其潜在原因: 1. **目标节点资源配置不足** 如果目标节点缺乏足够的内存、磁盘空间或其他必要资源,则可能导致冷迁移失败。Nova调度器会尝试验证目标节点是否有足够的容量来接收迁入的实例[^1]。 2. **网络配置不一致** 冷迁移要求源节点和目标节点具有相同的网络环境设置。如果两者的Neutron网络配置存在差异(例如VLAN ID冲突),则可能会导致通信中断或IP地址分配失败[^2]。 3. **存储后端不匹配** 当使用共享存储作为虚拟机镜像存放位置时,需确保所有参与迁移过程的计算节点都能访问同一份数据副本;否则容易造成文件权限变更或者丢失现象发生,比如`console.log`, `disk` 文件属主变为 root/root 的情况就是典型例子之一. 4. **CPU架构不兼容** 对于某些特定场景下的热迁移而言 (尽管这里是讨论冷迁移),仍然需要注意源主机与目标主机之间是否存在 CPU 特性的差别。假如采用了过于严格的 cpu_mode 设置(如 'host-passthrough') ,那么即使是在冷迁移期间也有可能因为新旧服务器间处理器型号不符而遭到拒绝执行请求的结果出现[^3]. 5. **身份认证失效** 另外还有可能是由于 token 过期等原因引起的身份验证异常问题,在日志里表现为 unauthorized 类型的信息提示[^2]. #### 二、解决方案 针对以上提到的各种可能性提供相应的处理措施如下: 1. 验证并调整目标节点上的可用资源状态, 确认满足待转移工作负载需求. 2. 审查整个集群范围内关于 Neutron 所定义的各项参数设定是否统一无误. 3. 检查存储子系统的连接状况, 并修复任何妨碍正常运作的因素; 同时考虑实施自动化脚本来定期纠正因迁移动作所引起的意外更改行为. 4. 根据实际业务需要合理选择合适的 cpu_mode 方式 ('host-model' 或者 'custom'), 尤其当涉及到异构物理设备部署的时候更要谨慎权衡利弊得失. 5. 更新 Keystone service 来延长 tokens 生命周期或是重新获取新的有效凭证后再试运行命令操作. ```bash # Example of checking available resources on destination node nova hypervisor-stats --detail | grep free_ram_mb ``` ```python from keystoneauth1 import session as ks_session from keystoneauth1.identity import v3 def get_new_token(): auth = v3.Password(auth_url="http://keystone.example.com/v3", username='admin', password='password', project_name='service') sess = ks_session.Session(auth=auth) return sess.get_token() ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值