创建虚拟机
# nova boot –image e5599ed9-261d-4ce1-b992-72cc3fa689c0 –flavor 1 –nic net-id=4e6a4b1a-7dfb-40a2-8a6c-ff8b824f38cf test03
查看虚拟机却发现有2个IP
# nova list
+————————————–+——–+——–+————+————-+—————————–+
| ID | Name | Status | Task State | Power State | Networks |
+————————————–+——–+——–+————+————-+—————————–+
| 1cfb7191-849f-42ac-80df-4d568dbc2826 | test03 | ACTIVE | – | Running | private=10.0.0.7, 10.0.0.14 |
+————————————–+——–+——–+————+————-+—————————–+
尝试了多次之后，发现一个特点，这些虚拟机都是在同一个计算节点上ocata02上（我这里ocata02和ocata01节点，ocata01还是控制网络节点）
我这里ocata01节点是8CPU+16GB内存，ocata02节点4CPU+8GB内存，理论上我创建的虚拟机应该首先是在ocata01上，而不是在ocata02上。
那么这里可以推测：虚拟机创建首先调度的是ocata01，但是在ocata01上失败了，又重调度到ocata02，成功了。但每次调度都会请求分配IP，所以分配了2次。（这里应该存在bug，而且我在J版、M版、还有这次的O版都遇到了，唉，一个大Bug几年几版都不修复）
验证下自己的推测，分别在ocata01和ocata02上创建虚拟机看看
# nova boot –image e5599ed9-261d-4ce1-b992-72cc3fa689c0 –flavor 1 –nic net-id=4e6a4b1a-7dfb-40a2-8a6c-ff8b824f38cf –availability-zone nova:ocata01 test-ocata01
# nova boot –image e5599ed9-261d-4ce1-b992-72cc3fa689c0 –flavor 1 –nic net-id=4e6a4b1a-7dfb-40a2-8a6c-ff8b824f38cf –availability-zone nova:ocata02 test-ocata02
# nova list
+————————————–+————–+——–+————+————-+—————————–+
| ID | Name | Status | Task State | Power State | Networks |
+————————————–+————–+——–+————+————-+—————————–+
| 6a117b01-897d-44c9-ac05-a6f2a6406c92 | test-ocata01 | ERROR | – | NOSTATE | |
| 3ada201e-8bf5-41f9-9f63-99f07af0168a | test-ocata02 | ACTIVE | – | Running | private=10.0.0.15 |
| 1cfb7191-849f-42ac-80df-4d568dbc2826 | test03 | ACTIVE | – | Running | private=10.0.0.7, 10.0.0.14 |
+————————————–+————–+——–+————+————-+—————————–+
这里发生了一个有趣的现象：
1，在ocata01上创建的虚拟机报错了，没成功
2，在ocata02上创建的虚拟机成功了，而且只有1个ip，这是正常的
到这里可以证明我的推理是正确的。当然还的继续通过日志来看。
首先，在nova-api中确实发现test03即1cfb7191-849f-42ac-80df-4d568dbc2826这个虚拟机先在ocata01上创建网络，然后又在ocata02上创建网络，中间相差约10秒。
2017-07-13 11:37:56.984 5990 INFO nova.api.openstack.compute.server_external_events [req-dc9a785f-3f26-4daa-a0f2-78594ba6ce24 2f62e1dd069045128b2431d874c53cfe 4c6b442053284f12be85eda6c1ff
de4d – default default] Creating event network-changed:None for instance 1cfb7191-849f-42ac-80df-4d568dbc2826 on ocata01
….
2017-07-13 11:38:06.745 5984 INFO nova.api.openstack.compute.server_external_events [req-8c355dcd-9089-42b3-9b1e-f7c3fc9bade0 2f62e1dd069045128b2431d874c53cfe 4c6b442053284f12be85ed
a6c1ffde4d – default default] Creating event network-vif-plugged:68947fa9-db4b-4bec-b8d2-8e46ac3ea84c for instance 1cfb7191-849f-42ac-80df-4d568dbc2826 on ocata02
其次，为什么ocata01上创建不成功呢？在ocata01的nova-compte日志中，发现老多报错了
ERROR nova.virt.libvirt.guest [req-42e5aeb6-2720-4f8f-9b64-edafb0d4e4dc e42425d992e94131995130770984e6fb 52e0821dd4b04982949831684bf252e6 – – -] Error launchi
ng a defined domain with XML: <domain type=’qemu’>
…
ERROR nova.virt.libvirt.driver [req-42e5aeb6-2720-4f8f-9b64-edafb0d4e4dc e42425d992e94131995130770984e6fb 52e0821dd4b04982949831684bf252e6 – – -] [instance: 1
cfb7191-849f-42ac-80df-4d568dbc2826] Failed to start libvirt guest
…
ERROR nova.compute.manager [req-42e5aeb6-2720-4f8f-9b64-edafb0d4e4dc e42425d992e94131995130770984e6fb 52e0821dd4b04982949831684bf252e6 – – -] [instance: 1cfb7
191-849f-42ac-80df-4d568dbc2826] Instance failed to spawn
…
ERROR nova.compute.manager [instance: 1cfb7191-849f-42ac-80df-4d568dbc2826] libvirtError: internal error: qemu unexpectedly closed the monitor: 2017-07-13T03:
37:58.023029Z qemu-kvm: cannot set up guest memory ‘pc.ram’: Cannot allocate memory
…
ERROR nova.compute.manager [req-c3dc6ca6-c344-4fc8-8619-a3f94679c4e8 – – – – -] Error updating resources for node ocata01.
…
ERROR nova.compute.manager MessagingTimeout: Timed out waiting for a reply to message ID 368d8e188e7a481b8177c094e078e373
…
结合nova-api日志和nova-compte日志更加可以肯定我的推测了。
bug，我是没能力解决，也懒的google了，几年后的版本还存在这个问题，那么应该也不会搜出什么东西来。所以只能把ocata01的病治好，或者以后每次都创建指定到ocata02上(- -!)还是治疗ocata01为上策。
查看下libvirtd状态，大量的下面两行错误：
# systemctl status libvirtd
internal error: process exited while connecting to monitor: 2017-07-13T03:37:36.016833Z qemu-kvm: cannot set up guest memory ‘pc.ram…ocate memory
Unable to read from monitor: Connection reset by peer
既然日志很多条目都剑指libvirt，那么直接重启libvirt和nova-compute看看
# systemctl restart libvirtd
# systemctl restart openstack-nova-compute.service
再次在ocata01上创建虚拟机依旧不行！！
再回头看看上面的日志：qemu-kvm: cannot set up guest memory ‘pc.ram’: Cannot allocate memory
不能分配内存？赶紧看下ocata01上的内存：
[root@ocata01 ~(keystone_admin)]# free -m
total used free shared buff/cache available
Mem: 15886 14759 210 617 916 226
Swap: 0 0 0
ocata01节点还剩下210M的内存，而且是禁用swap的。而我的falvor需求的内存是512M。既然不满足内存需求，怎么还会调度到ocata01呢？
再看下ocata01上的nova的内存超分情况：
# grep ram_allocation_ratio /etc/nova/nova.conf
ram_allocation_ratio=1.5
因为这个1.5倍的超分比，所以nova调度的时候会认为ocata01任然有资源可用，但是实际却不行，这里也看出了超分的恶果
禁用超分
# sed -i ‘s/ram_allocation_ratio=1.5/ram_allocation_ratio=1/g’ /etc/nova/nova.conf
# systemctl restart openstack-nova-api 再次创建虚拟机，不指定节点
# nova boot –image e5599ed9-261d-4ce1-b992-72cc3fa689c0 –flavor 1 –nic net-id=4e6a4b1a-7dfb-40a2-8a6c-ff8b824f38cf test02
确认下已经正常，问题解决。
# nova list
+————————————–+—————+——–+————+————-+—————————–+
| ID | Name | Status | Task State | Power State | Networks |
+————————————–+—————+——–+————+————-+—————————–+
| 6a117b01-897d-44c9-ac05-a6f2a6406c92 | test-ocata01 | ERROR | – | NOSTATE | |
| 3ada201e-8bf5-41f9-9f63-99f07af0168a | test-ocata02 | ACTIVE | – | Running | private=10.0.0.15 |
| 59591ab8-fe54-4244-8a2e-80141012d644 | test02 | ACTIVE | – | Running | private=10.0.0.8 |
| 1cfb7191-849f-42ac-80df-4d568dbc2826 | test03 | ACTIVE | – | Running | private=10.0.0.7, 10.0.0.14 |
+————————————–+—————+——–+————+————-+—————————–+
后话：上面也算是临时办法，更实际的处理办法其实就是给ocata01加内存。
当然，最彻底的办法还是希望openstack修复了那个万恶的bug，即在发现ocata01上调度创建失败，重新调度去ocata02的时候，要把在ocata01上分配的那个port给清理掉啊。或者就是发现ocata01上调度分配的port没问题的话，那么调度到ocata02的时候就别再分配port啊。
