今天在并发migrate的时候，由于一批节点是新上nova-compute服务还处于disable状态，而且迁移必须会更换新节点，导致迁移到一些没有空余资源的节点上出现了ERROR，因此也没太放心上，但是结束之后，随后对一台云主机进行了resize操作，正常返回，但是没有任何修改规格的动作引起了我的注意，因此仔细研究了一下
首先直接调用nova接口进行修改规格
$ nova resize f72ebb92-084e-4700-aec1-f16910c88de0 2
可是令人诡异的是，虚拟机返回了，但是没动静，通过–debug查看API的返回结果，居然也是空
REQ: curl -i 'http://xxx.xxx.xxx.xxx:8774/v2/1c32d3e9bbe9419f85b37b4a6c0e2f3e/servers/f72ebb92-084e-4700-aec1-f16910c88de0/action' -X POST -H "X-Auth-Project-Id: Project_yiqiao_private" -H "User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: f79b45e3e9824298af1ad98752a0e0d0" -d '{"resize": {"flavorRef": "2"}}'
DEBUG (connectionpool:375) Setting read timeout to 600.0
DEBUG (connectionpool:415) "POST /v2/1c32d3e9bbe9419f85b37b4a6c0e2f3e/servers/f72ebb92-084e-4700-aec1-f16910c88de0/action HTTP/1.1" 202 0
RESP: [202] CaseInsensitiveDict({'date': 'Fri, 28 Oct 2016 15:29:39 GMT', 'content-length': '0', 'content-type': 'text/html; charset=UTF-8', 'x-compute-request-id': 'req-20d72f35-f138-45a6-bf8e-333f135ee2f9'})
RESP BODY:
如此那就记录下reqeustID，直接搜nova日志得了
$ grep req-20d72f35-f138-45a6-bf8e-333f135ee2f9 /data/log/nova/nova-scheduler.log --color
可以从API开始搜起，但是就直接倒着搜，先看nova-scheduler日志，在控制节点上能够找到
2016-10-28 23:29:39.747 2742 INFO nova.filters [req-20d72f35-f138-45a6-bf8e-333f135ee2f9 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3e] Filtering removed all hosts for the request with reservation ID 'r-1uyxta06' and instance ID 'f72ebb92-084e-4700-aec1-f16910c88de0'. Filter results: ['RetryFilter: (start: 227, end: 227)', 'AvailabilityZoneFilter: (start: 227, end: 41)', 'RamFilter: (start: 41, end: 40)', 'ComputeFilter: (start: 40, end: 35)', 'ImagePropertiesFilter: (start: 35, end: 35)', 'JsonFilter: (start: 35, end: 35)', 'EcuFilter: (start: 35, end: 35)', 'AggregateCoreFilter: (start: 35, end: 6)', 'CephFilter: (start: 6, end: 0)']
这是一个十分令人惊讶的filter结果，居然被CephFilter给筛选为空了，为此查看了节点计算存储和虚拟机镜像，均是Ceph类型，看到这里只能说心中顿时有上千匹那马
仔细分析一下，目前上的这批节点nova-compute服务都是disable的，resize是绝对不会调度到这些节点上的，因此查看了剩下同一个可用域下面所有节点，也就是CephFilter上面start后面的6个，看看到底是什么ceph相关的东西，把他们都给过滤掉了
再次查看计算存储是否都是Ceph，经过确认，的确都是Ceph，这下就迷茫了
没办法继续逐行看下调度日志，看周围能否看到线索，这次直接连ceph一起检索
$ grep req-20d72f35-f138-45a6-bf8e-333f135ee2f9 /data/log/nova/nova-scheduler.log | grep ceph --color
终于，发现了一点蛛丝马迹，这里一个列表里面ceph对应的switch03_sas_vms
2016-10-28 23:29:39.604 2742 DEBUG nova.scheduler.filters.image_props_filter [req-20d72f35-f138-45a6-bf8e-333f135ee2f9 2eafeb9a3d184115bfc0ba6a61c1f4b9 1c32d3e9bbe9419f85b37b4a6c0e2f3e] Instance properties {u'domain': u'nasyqpri.netease.com', u'instance_type_name': u'flavor_1', u'image_state': u'available', u'use_ceph': u'yes', u'base_image_ref': u'9a60713c-204f-4797-b5b4-2330e47fafc9', u'user_id': u'2eafeb9a3d184115bfc0ba6a61c1f4b9', u'image_type': u'snapshot', u'instance_type_ecus': u'1', u'instance_type_ephemeral_gb': u'0', u'owner_id': u'1c32d3e9bbe9419f85b37b4a6c0e2f3e', u'image_location': u'snapshot', u'instance_type_root_gb': u'20', u'instance_type_id': u'1', u'hw_qemu_guest_agent': u'yes', u'instance_type_rxtx_factor': u'1', u'instance_type_vcpus': u'1', u'instance_uuid': u'0ee5bef2-9ae9-44f5-bd30-dae36adffede', u'instance_type_memory_mb': u'512', u'instance_type_swap': u'0', u'hypervisor_type': u'qemu', u'ceph_pool': u'switch03_sas_vms', u'instance_type_flavorid': u'1'} are satisfied by compute host supported_instances[[u'i686', u'qemu', u'hvm'], [u'i686', u'kvm', u'hvm'], [u'x86_64', u'qemu', u'hvm'], [u'x86_64', u'kvm', u'hvm'], [u'ceph', u'switch03_sas_vms']] _instance_supported /usr/lib/python2.7/dist-packages/nova/scheduler/filters/image_props_filter.py:71
顿时恍然大悟，难不成在不同的pool，在不同的隔离单位中，直接查询目标节点，也就是理论上满足迁移资源的节点
libvirt_images_rbd_pool = switch04_sas_vms
类似的，查询所有的结果，都没有在switch03_sas_vms这个pool里的，这才是真正被CephFilter给过滤掉的真正原因
在不同的计算节点上，都会配置好不同的ceph pool，因此这也成为了nova-scheduler中filter的一个点，容易被忽略
因此虽然接口并没有返回错误，但是实际上已经被scheduler给过滤掉了所有满足资源要求的节点，没有执行resize操作，原因就因为没有满足要求的相同的ceph pool
