9月8日更新：解釋及解決辦法
解釋
OpenStack中有兩種ip地址的概念：fixed ip和floating ip。fixed ip 是實例的真實ip，在創建實例時注入，如果操作系統不支持注入如windows，OpenStack會在實例啓動後通過dhcp方式把fixed ip分配給實例。floating ip是nova-network節點通過iptables 的SNAT/DNAT實現的，就是在nova-network進行floating ip到fixed ip轉化，這依賴於實例能獲得正確的fixed ip。在我的環境裏除了nova-network使用的dnsmasq外還存在着另外的dhcp服務器，如果實例在nova-network啓動前啓動了，則會從其它的dhcp獲取ip顯然我通過fixed ip來連接實例就不行了，fixed ip不對，floating ip也就無從談起。另外nova-network重啓後不會重建與dhcp服務器有關的防火牆規則，而默認CentOS/RHEL是不開放這些端口的。這就導致nova-network重啓後已有的實例無法繼續使用它們獲取的fixed ip。新建的實例更無法獲取fixed ip了。
解決辦法
移除OpenStack環境中的外部dhcp服務器，防止外部dhcp對實例的影響，關於nova-network重啓的bug參考這裏修改：https://github.com/openstack/nova/commit/bc621bca08d51076bd81f15e29e8b89ea946503a
這是偶然發現的問題，設置好網橋後，發現重啓服務器後實例的狀態可以自動恢復到重啓前，於是各種高興，但是卻發現了實例的網絡聯通性問題。
前面提到過，控制節點上nova-network運行後，會將br100的ip設置成10.0.0.1，並通過iptables的NAT功能映射原來設置的ip地址。這樣在控制節點就可以ping能實例或通過ssh連接實例，也可通過原來的ip訪問控制節點。
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實例！