OpenStack虚机迁移live-migration失败(error: internal error Attempt to migrate guest to the same host)
现象:执行迁移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服务,再执行迁移即可成功!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
欺壹世充电系列之[Svn集中式版本管理系统]
Svn集中式版本管理系统 --欺壹世充电系列 一、svn服务器 1、什么是Svn svn(subversion)是一个垮平台的开源版本控制系统。管理随时间改变的各种数据。svn会备份并记录每个文件每一次的修改更新变动,这样我们就可以把任意一个时间点的档案恢复到想要的某一个旧的版本。 2、Svn与Git svn是集中式的管理,存在一个中央版本库,所有开发人员在本地开发所有使用的代码都来自于这个版本库,提交代码也都必须提交到这个中央版本库。 svn版本控制系统流程如下: 1.在中央库上创建或从主干复制一个分支。 2.从中央库checkout下这个分支代码。 3.添加自己的代码文件,修改现存的代码或者删除代码文件。 4.commit代码,假设有人在刚刚的分支上提交了代码,你就会被提示代码过期,你得先up你得代码后在提交。up代码的时候如果出现冲突,需要解决好冲突后再进行提交。 缺点: 如果无法连接到中央版本库的环境下,你无法提交代码,将代码加入版本控制,无法查看代码的历史版本,以及版本变化过程。由于代码库集中管理,因此,需要对中央版本库的存储做备份。svn...
- 下一篇
利用Registrator和Consul实现mesos task的服务发现
实现目的: 因为mesos中实际的工作节点是slave,框架marathon启动的任务(容器)都是在随机的slave上执行,所以在每台slave上启动Registrator,用来发现本机上的容器,它会把当前宿主机上的容器自动注册到consul.但是consul找一台salve启动就行,它会把自己选为leader,其他slave上启动Registrator的时候指定此leader就行 环境: 192.168.0.149 Mesos-master、Zookeeper 192.168.0.161 Mesos-master、Zookeeper、Marathon 192.168.0.174 Mesos-master、Zookeeper 192.168.0.239 Mesos-slave、Consul-server、Registrator 192.168.0.236 Mesos-slave、Registrator 部署: 定义IP HOST_IP_1=192.168.0.149 HOST_IP_2=192.168.0.161 HOST_IP_3=192.168.0.174 192.168.0.14...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2整合Redis,开启缓存,提高访问速度