前言
甲方的云平台新到了一些海光的机器，希望能加入到已有的计算集群里面。问题不大，但是有些小的点需要处理。
已有的经验
去年的时候使用海光7265部署过openstack云平台，平台运行没有问题，但是虚拟机运行有个小问题，处理之后发现只有使用海光定制的centos源文件制作的镜像才可以正常在海光的服务器上运行。
这里就引出来的在新场景下的使用问题。甲方现有的计算节点都是intel的，是x86的。海光的CPU也是X86的。
必须要保证海光的云主机运行在海光计算节点上，通用的x86云主机运行在intel计算节点上。
备注：划分可用区然后在创建云主机时选可用区，这个方式不考虑。最终要得到的使用流程是用户直接选择镜像就创建，不做额外的多余配置。
思路一：image元数据
使用image的元数据进行定义，首先想到的是architecture，之前做过一个平台包含两个架构的资源池时使用过这个元数据。
给image增加元数据
architecture=aarch64
如果是x86_64 指定
architecture=x86_64
一想又不对，海光的CPU也是x86的。
区分不了，这个思路直接pass掉。
思路二：flavor元数据
老师那边给了新思路，使用flavor的元数据也可以支持，而且经过实验了。但是这里有引入了一个新的问题，就是用户不一定会选我们定制的flavor来创建云主机。实际上是需要改变用户使用习惯。也pass掉
nova flavor extra-specs
capabilities:cpu_info:vendor
Intel，AMD，Hygon
openstack flavor set cmd-1-1-1-cpu-vendor --property capabilities:cpu_info:vendor= Hygon
思路三、IsolatedHostsFilter：使用filter来限制
发现这个是最合适的。设定特定的镜像组只可以在特定的计算节点组上运行。对于这次的场景来说非常完美，对用户无感。
配置上filter之后测试一下，完美通过。
下面记录一下相关的资料来源和我的测试配置
资料来源链接: https://docs.openstack.org/nova/latest/admin/scheduling.html#imagepropertiesfilter
资料来源链接: https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.restrict_isolated_hosts_to_isolated_images
我的配置文件，nova-scheduler服务的nova.conf文件
# 在末尾增加IsolatedHostsFilter
enabled_filters=AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,PciPassthroughFilter,IsolatedHostsFilter
# node29是我的划出来的测试物理机
isolated_hosts = node29
# 这两个镜像是测试的镜像
isolated_images = 7137e2a8-2436-4811-b594-e0f8caaac9c6, 0bec0769-ed64-43a4-b9aa-6486aac9ac39
测试过程就是创建虚拟机。在创建的时候，不要选择可用区，只选择镜像就可以了。等待创建完毕之后会发现通过测试镜像创建出来的虚拟机都会被指定调度到node29机器。
下面我贴几张nova-scheduler的日志图片
1、配置读取成功
2、开始创建测试云主机
3、开始选择
4、IsolatedHostsFilter返回的筛选结果
总结
这次使用IsolatedHostsFilter是个特定场景下的特定选择，至少是找到了解决方案，有遇到类似场景的朋友可以试着用一下，也是一种折中的方案。