迁移填坑第二季

背景

之前说到，配置了迁移环境碰到了各种坑，然后终于解决掉了，终于能够nova live-migration kobe compute5了。。。然后就开始批量生产迁移环境，然后。。

坑一：cpu features不支持（cpu set）

之前是只用了compute3和compute5，然后把compute6和compute7也配置好nfs和libvirt，然后尝试把kobe迁到6，失败！回滚到active状态，看起来是pre check的时候的问题，然后迁到7，失败！好像是同样的问题。。看了下日志，说的是check_can_live_migration_destination出错，但是compute6上的日志内容很奇怪，然后突然想起来之前第一次填坑的时候愤怒的把compare_cpu注释掉了。。恢复之后，重新来失败一次。。果然，日志说destination的cpu不兼容，compute6上说cpu set 2 4 6 8 （忘了，大概是这样子＃TODO），然后看了一下6 和 7的cpu，果然比较老，支持的cpu features比较少（但是没有深究这个cpu features是干嘛的）。

那这个如何是好。。。就算可以从6迁回去，但是迁不回来有毛用啊。我那时候突然冒出来一个十分伟大的想法：写一个假的程序模拟那些不支持的features，因为cpu的model是我可以指定的，只要避开那些不支持的feature，其他的只要检查一下是否存在就好了。然后估算了一下，这玩意儿涉及到了系统的更底层，复杂度更一步增加，然后。。就没有然后了。。

结局：这个坑挖出来只能避开它。。

坑二惊魂：NFS共享存储的UID和PID会变，然后。。虚拟机起不起来了。。

然后等compute1 compute2 compute4装好，先确认过这几台是比较新的DELL，然后配置好之后，愉快的玩了半天，1到2，2到3，3到4，4。。。。。

4又怎么了！！！

看日志，是权限错误？？/var/lib/nova/instances

卧槽，owner怎么变成libvirt-dnsmasq了。。还我nova啊啊啊

好吧，淡定点，删掉它，重新启一个。。咦？error，no valid hosts？再来一发。。no valid hosts .....again , again again and again

然后chown nova:nova instances

然后在试，我擦擦，controller也变了，变成neutron，其他的节点有的变了有的没有。

...............中午饭都顾不上吃了，觉也顾不上了，和同学开始进入疯狂思考模式。

问题大概是这样的，controller里nova的uid是110，neutron是108. compute1，2，3，5里nova是108，libvirt－dnsmasq是110，compute4里nova是111？忘了。。反正跟其他的compute都不一样。

各种挂载，映射，修改uid，就差去换一个共享存储了。（这里还是有点偷懒，没有去看nfs关于权限的规定，我记得并且从现象上看是根据uid）

然后失败，3点左右去吃饭睡觉写会rails压压惊。

快6点的时候和同学去食堂吃饭，然后详细的捋了一遍，我隐约发现了问题。。这貌似是第一次在食堂还这么激烈的讨论和思考。

我们回到实验室的时候有这么几个打算：

1，我再试试，按照我的思路要先取消挂载，然后挨个节点尝试一下。。

2，重新装机，每个节点的nova的uid都要强行一致。

3，换实验室。。。。。。。

运气不错，先把其他都关掉，只留下一个compute1，然后 umount /var/lib/nova/instances

然后在controller和compute1上chown -R nova:nova /var/lib/nova/instances 

然后重新mount -a -v 

然后nova boot。。神奇的事情出现了！成功的找到了compute1并spawn了。

然后如法炮制，compute2，然后迁移。。果然成功！！

然后除了4，其他都启起来了。。。迁移完全没问题了。。

大喜到大悲再到大喜。。。