189 8069 5689
这期内容当中小编将会给大家带来有关大数据在线迁移的常见问题是怎么解决的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
成都创新互联公司是专业的融安网站建设公司，融安接单;提供成都网站制作、网站建设、外贸网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行融安网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
大致描述一下场景：系统采用了计算存储松耦合结构，虚机的映像文件在远端共享存储上，所以迁移起来速度很快。在我们系统中，最快一个用了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 http://libvirt.org/html/libvirt-libvirt.html#virCPUCompareResult\n"]
解决办法：
目前还没有解决办法
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的端口自己会调整。
上述就是小编为大家分享的大数据在线迁移的常见问题是怎么解决的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。