深圳做网站哪家公司好/百度关键词竞价

现象：执行迁移live-migration操作后，显示成功迁移，但是实际没有执行迁移动作

解决过程：

在dashboard执行虚机热迁移操作，提示操作成功，但是实际虚机没有迁移；

 

之前遇到过内存不足导致迁移失败，但是经过查看发现源和目的节点资源充足；

 

然后在nova的log看到如下内容：DestinationDiskExists_Remote: The supplied disk path (/var/lib/nova/instances/e40708e3-7f19-4f9c-8d19-3e600037c067) already exists, it is expected not to exist.，初步怀疑对端已经建立了该目录，但是由于未知原因没有迁移成功，再次迁移触发这个报错，但是实际发现目的节点并没有该目录，然后继续翻查log。

 

然后找到log如下：2016-03-24 15:44:21.003 3164 ERROR nova.virt.libvirt.driver [-] [instance: e40708e3-7f19-4f9c-8d19-3e600037c067] Live Migration failure: internal error: Attempt to migrate guest to the same host 00020003-0004-0005-0006-000700080009，初步怀疑虚机之所以没有迁移是因为它认为目的主机就是自己，所以我看了下hosts，主机解析正常。

 

这让我想起很早遇到的一个VMware迁移的问题，就是很多厂商都是OEM服务器，导致UUID一样。

 

使用virsh sysinfo | grep uuid或者dmidecode -s system-uuid都可以查询服务器的UUID，结果查询到计算节点的UUID都是一样的，所以导致迁移的时候源主机认为目的主机就是自己。

 

KVM并不是直接查找这个硬件的UUID而是先到/etc/libvirt/libvirtd.conf内找host_uuid字段，但是此字段是被默认注释掉的，所以找到对方硬件的UUID。

 

解决方法：

先随机生成一个UUID，如下：

[root@node-1 ~]# cat /proc/sys/kernel/random/uuid 
4165c128-e7ba-45cd-a26f-325d221c2ace

 

然后使用上面的uuid替换/etc/libvirt/libvirtd.conf中的host_uuid字段

#host_uuid = "00000000-0000-0000-0000-000000000000"  改为

host_uuid = "4165c128-e7ba-45cd-a26f-325d221c2ace" 

 

所有计算节点都修改完成后，重启libvirt服务，再执行迁移即可成功！

 

转载自：http://blog.51cto.com/tianhunyongheng/1758195