这是偶然发现的问题，设置好网桥后，发现重启服务器后实例的状态可以自动恢复到重启前，于是各种高兴，但是却发现了实例的网络联通性问题。
前面提到过，控制节点上nova-network运行后，会将br100的ip设置成10.0.0.1，并通过iptables的NST功能映射原来设置的ip地址。这样在控制节点就可以ping能实例或通过ssh连接实例，也可通过原来的ip访问控制节点。
但是重启服务器后，实例是恢复了，但运行相关服务后在控制节点用ping命令来ping各实例时却出问题了：
1.在控制节点运行除nova-compute的服务后，控制节点实例无法ping通，启动nova-compute，如果没有设置让实例随nova-compute的运行重启，仍然无法ping能，如果实例随nova-compute重启了就可以ping通。
2.如果计算节点重启在控制节点的各服务运行后，即使不启动nova-compute也行从控制节点ping通其上的实例，如果计算节点在控制节点各服务运行前启动了，其上的实例ping结果跟控制节点是一样的。
3.在控制节点和计算节点实例都能从控制节点ping能的情况下，重启控制节点并启动相关服务，无法ping通计算节点的实例，设置计算节点的实例随nova-compute重启而重启后，重启nova-compute，计算节点的实例能ping通了。
4.在控制节点和计算节点实例都能从控制节点ping能的情况下，一个一个重启控制节点的服务，测试各实例的ping结果，发现nova-scheduler终止后所有实例都无法ping通，重启后也无法ping后，即使此时重启所有nova服务包括nova-compute并让实例随其重启也无法ping通（甚至我还重启了libvirtd)，必须要重启控制节点才行。
从以上实验可以得出以下结论：
在nova相关服务运行前已经启动的实例无法ping通（需要重启实例才行），在其后启动的实例即使没有运行nova-compute也能ping通。如果nova-scheduler被终止再启动，必须要重启控制节点，否则无论如何也无法ping实例！