刚刚在多并发冷迁移的过程中，脚本运行后出现了一大排的ERROR
[2016-10-28 15:16:02][pri1-nova154.openstack.org]Error: VM 32fc6596-d4ab-4ca8-91c3-1c8578ca9fbf is ERROR, please check it [2016-10-28 15:16:04][pri1-nova161.openstack.org]Error: VM 4b8bb360-d9dd-451b-939d-dd399b7f901c is ERROR, please check it [2016-10-28 15:16:04][pri1-nova160.openstack.org]Error: VM 91fa762b-18e5-4829-bf63-eb804e785cb2 is ERROR, please check it [2016-10-28 15:16:04][pri1-nova156.openstack.org]Error: VM 89056f0b-9bb6-4e33-a912-7282d58f363d is ERROR, please check it [2016-10-28 15:16:04][pri1-nova157.openstack.org]Error: VM c71fa73e-7f71-4d85-88cd-a7b5f0bbb2c4 is ERROR, please check it [2016-10-28 15:16:04][pri1-nova159.openstack.org]Error: VM d61e7e94-290b-4b5c-9e6e-0dee0c5ee551 is ERROR, please check it [2016-10-28 15:16:04][pri1-nova163.openstack.org]Error: VM e87319a4-ac23-4c19-a130-e4a49868c59f is ERROR, please check it [2016-10-28 15:16:04][pri1-nova158.openstack.org]Error: VM 65ffefa4-3dca-4ae8-b9b0-a8a9883a48c4 is ERROR, please check it
这是新上节点，应该是老节点都没有物理资源的缘故导致，通过调用nova接口查看ERROR状态的虚拟机，错误信息为
message": "Insufficient compute resources
果真是没资源了，但为了确认一下，还是将相同可用域的可用节点扫了一遍，突然眼睛一亮，找到了一个节点资源十分空闲的节点，但是却没有虚拟机调度上来，却调度到没有物理资源的节点上，因此多思考了一下
首先还是查看LOG，日志说明一切
先看API日志，随便挑选一个虚拟机UUID，比如32fc6596-d4ab-4ca8-91c3-1c8578ca9fbf，这时候脚本里打印日志的时间戳就格外重要了，API节点那么多，如果没有ELK，就需要一个一个API节点来检索接口的操作动作，有一个确切的时间容易快速找到
这里没有ELK，根据15:16:00左右的时间点来找，很快能够找到API调用migrate的地方
2016-10-28 15:15:58.563 2935 DEBUG nova.api.openstack.wsgi [req-acfad281-090d-4d37-831b-bdedeceff3d5 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3e] Action: 'action', body: {"migrate": null} _process_stack /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:940
2016-10-28 15:15:58.564 2935 DEBUG nova.api.openstack.wsgi [req-acfad281-090d-4d37-831b-bdedeceff3d5 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3e] Calling method > _process_stack /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:941
找到这个地方主要的原因是找出对应的requestID，继续在API日志里面检索后续的动作，为什么呢，因为调用了migrate命令后，API收到响应，然后会传到Scheduler进行筛选过滤，挑选出一个最合适的节点，会返回给API，也就是API日志里其实可以最终搜到最合适的哪一个迁移的目标节点，先将这个节点给挖出来，确认是否真的是物理资源不够
2016-10-28 15:16:02.018 2935 DEBUG nova.openstack.common.rpc.amqp [req-acfad281-090d-4d37-831b-bdedeceff3d5 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3e] Making asynchronous cast on compute.pri1-nova180.openstack.org... cast /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py:586 2016-10-28 15:16:02.019 2935 DEBUG nova.openstack.common.rpc.amqp [req-acfad281-090d-4d37-831b-bdedeceff3d5 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3e] UNIQUE_ID is 1fb54f72972145deb7b68a3bf7078ded. _add_unique_id /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py:341
找着找着不小心就找到了我们的目标：compute.pri1-nova180.openstack.org…
看到这里，立马看下nova180，果真没资源了，VCPU用尽导致，继续确认日志，看Scheduler
2016-10-28 15:16:00.335 195267 DEBUG nova.filters [req-7a578ff5-2e78-410b-8168-5219efa84f9b 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3 e] Filter EcuFilter returned 36 host(s) get_filtered_objects /usr/lib/python2.7/dist-packages/nova/filters.py:108 2016-10-28 15:16:00.465 195267 DEBUG nova.filters [req-7a578ff5-2e78-410b-8168-5219efa84f9b 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3 e] Filter AggregateCoreFilter returned 8 host(s) get_filtered_objects /usr/lib/python2.7/dist-packages/nova/filters.py:108 2016-10-28 15:16:00.466 195267 DEBUG nova.filters [req-7a578ff5-2e78-410b-8168-5219efa84f9b 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3 e] Filter CephFilter returned 1 host(s) get_filtered_objects /usr/lib/python2.7/dist-packages/nova/filters.py:108 2016-10-28 15:16:00.466 195267 DEBUG nova.scheduler.filter_scheduler [req-7a578ff5-2e78-410b-8168-5219efa84f9b 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9 419f85b37b4a6c0e2f3e] Filtered [(pri1-nova180.openstack.org, pri1-nova180.openstack.org) ram:101445 disk:1420288 io_ops:0 instances:28] _schedule /usr/lib/python2 .7/dist-packages/nova/scheduler/filter_scheduler.py:353 2016-10-28 15:16:00.467 195267 DEBUG nova.scheduler.filter_scheduler [req-7a578ff5-2e78-410b-8168-5219efa84f9b 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9 419f85b37b4a6c0e2f3e] Weighed [WeighedHost [host: pri1-nova180.openstack.org, weight: 101445.0]] _schedule /usr/lib/python2.7/dist-packages/nova/scheduler/filt er_scheduler.py:358
这段十分关键，最开始EcuFilter，因为Ecu不过滤，所以较多，接着CoreFilter只剩下了8个节点，接着CephFilter按照Ceph类型以及pool过滤，就只剩下一个匹配了，因此nova180就是Scheduler经过筛选后最合适的节点，所以API日志里收到的就是这里得到的最合适节点
既然选中了这个节点，就按照冷迁移套路来，准备在这个节点新创建虚拟机，但是在此之前，每个节点nova-compute都有定时任务来检查resource情况，虽然已经调度到这个节点上来了，但是这台migrate还是ERROR了，原因就是定时任务发现没资源导致的，可这就奇怪了，调度的时候Scheduler明明筛选了有资源的节点，怎么会突然没资源呢，查看下这个节点最后创建的虚拟机情况就明白了，因为我是并发migrate测试，没迁移前这个节点只能容下1台最低配额的虚拟机，并发的时候已经有一台已经迁移上去了，导致节点资源VCPU耗尽，而在调度的时候，所有虚拟机还没迁移上去，定时任务资源检查还没上报，才会调度选中这个节点
下午在看这个问题的时候，没注意CephFilter，因为nova180也是剩余内存最多的节点，之前的调度策略是筛选出一批满足要求的节点之后，挑选那个剩余内存最多的节点作为迁移的目标节点
所以总体场景非常简单：
1：并发migrate，但有几个同样可用域的虚拟机根据所有的调度策略都只能迁移到同一个节点
2：目标节点资源只满足迁移一台过来，所以第二台以后的虚拟机就会全ERROR
其实这里还有一个问题思考：
假如这里CephFilter后还是筛选出了很多满足要求的节点，那么最终挑选free -m最多的节点，而此时我是并发操作，可见许多虚拟机一窝蜂都会往这一个节点上进行迁移，一方面导致系统性能下降，另一方面导致同一个节点负载剧增，感觉都不是一个十分良好的方案，说的更直白一点，10台1VCPU内存1G的虚拟机并发迁移，筛选后：
节点1：剩余内存100G，只能容纳5VCPU
节点2：剩余内存90G，能容纳10VCPU
节点3：剩余内存80G，能容纳15VCPU
……
节点9：剩余内存20G，能容纳45VCPU
节点10：剩余内存10G，能容纳50VCPU
由于我是并发执行，不出意外很有可能都全部调度到节点1上，这样就出现5台ERROR的虚拟机，原因就是节点1的剩余内存一直都是最多的
这样后期可能稍作改进，筛选出这批满足要求的节点之后，进行随机挑选调度最终最合适的节点，这样出错的几率稍小
