无妨先试一下这16个步骤 当发现你的OpenStack虚构机网络有疑问

1. Security Group所有关上，这是最基本的，然而很多人容易遗记

其实遇到过有数这种场景了，Debug了半天网络疑问，各种手腕都用上了，***发现安保组居然没有关上。

2. 经过界面检查虚构机的log，也可以在compute节点上检查console.log文件，看看外面能否有DHCP失掉IP成功的日志

在界面上可以看控制台日志

在compute节点上可以检查

/var/lib/nova/instances/6323a941-de10-4ed3-9e2f-1b2b25e79b66/console.log

假设没有日志，则说明image有疑问

在grub外面

linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=ttyS0

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0“

update-grub

3. 假设虚构机连不上DHCP Server，则须要预备一个不经常使用metadata server，而是用用户名明码可以登录的image

这种Image很好做，自己入手做一个就可以了，启动镜像后去掉cloud-init相关性能，而后设置一个自动的用户名明码。

4. 经过VNC登录

5. 假设VNC登录不出来，说明VNC性能的有疑问，方法一从新性能VNC

VNC Proxy的性能：

VNC Proxy的部署

VNC Proxy的运转环节：

6. 假设VNC登录不出来，还有一个方法，经常使用自己的VNC Client，经过compute物理节点的IP地址登陆

qemu-system-x86_64 有参数 -vnc 0.0.0.0:5

就可以经过compute node的ip地址进入

7. 经过ovs-vsctl show和brctl来检查，各个网卡和bridge之间相关能否正确，tunnel之间能否能够通，网卡能否都处于up的形态

8. 假设从虚构机的虚构网卡到DHCP Server的网卡一路都是性能正确的，则须要检查br-tun上ovs-ofctl dumpflows检查flows规定，能否对包的改写正确，能否有正确的规定

9. 经过VNC登录出来后，就可以经过命令行运转dhclient，来重启衔接DHCP Server, 从compute节点上的网卡和bridge，一个个启动tcpdump，看究竟哪个网卡或许bridge没有收到包，收到的包外面的VLAN ID等能否正确

10. 假设VM能从DHCP Server取得IP，则善报成了一半，接上去换一个有cloud-init的image，看metadata server能够衔接成功，能够注入key，也是经过console.log来看

11. 假设metadata server不能衔接成功，就须要顺着metadata server的整个流程，一个一个模块看，看每个模块的log，端口能否正确，能否收到恳求，也可以在VM外面用curl来模拟metadata server的恳求

openstack里的metadata，是提供一个机制给用户，可以设定每一个instance 的参数。比如你想给instance设置某个属性，比如主机名。

Instance访问metadata server

metadata的一个关键运行，是设置每个instance的ssh公钥。

失掉metadata的api接口是：

这个IP地址，在 openstack 是不存在的。为什么可以失掉到metadata呢？

这是由于Amazon的要素，最早metadata是亚马逊提出来的，参见：

起初很多人给亚马逊定制了一些操作系统的镜像，比如 ubuntu, fedora, centos 等等，而且将外面失掉 metadta 的api地址也写死了。所以opentack为了兼容，保管了这个地址169.254.169.254。

而后经过iptables nat映射到实在的api上：

iptables -A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 16.158.166.197:8775

nova如何区分究竟是哪个虚构机恳求metadata？采取的方法是在HTTP头部识别是哪个虚构机。

一个虚构机访问169.254.169.254的流程如下：

(1) 虚构机收回恳求

(2) namespace中的iptables

ip netns exec qrouter-5a74908c-712c-485c-aa9f-6c1e8b57e3e1 iptables -t nat -nvL

(3) namespace-metadata-proxy

启用namespace场景下，关于每一个router，都会创立这样一个进程。该进程监听9697端口，其关键性能：

1、向恳求头部减少X-Forwarded-For和X-Neutron-Router-ID，区分示意虚构机的fixedIP和router的ID

2、将恳求代理至Unix domain socket（/var/lib/neutron/metadata_proxy）

(4) Neutron-metadata-agent

network node上的metadata agent监听/var/lib/neutron/metadata_proxy：

该进程的性能是，依据恳求头部的X-Forwarded-For和X-Neutron-Router-ID参数，向Neutron service查问虚构机ID，而后向Nova Metadata服务发送恳求（自动端口8775），信息头：X-Forwarded-For，X-Instance-ID、X-Instance- ID-Signature区分示意虚构机的fixedIP，虚构机ID和虚构机ID的签名。

12. 假设metadata server能够衔接成功，key成功注入，下一步须要从namespace外面看能否能够ping通，能够ssh

13. 假设namespace外面能够成功，则在network节点上，ping floating ip和ssh，能否能够成功，假设不成功，看br-ex的网卡能否减少正确，能否性能了ip，路由表能否正确，namespace外面floating ip的iptables规定能否减少正确

14. 在network节点上能够ssh到floating ip，则须要从其余节点上ssh，假设不成功，或许br-ex的网址性能有疑问，很或许是br-ex减少的物理网卡不是混合形态，也或许是路由性能有疑问，关于floating ip所在的网段，不指向network节点

15. 假设floating ip能够成功，则须要出来VM外面运转apt-get update，假设无法以，看能否ping通openstack外面的gateway(10.0.0.1)，而后看能否ping通物理网络环境的gateway(16.158.XXX.1)

16. 看DNS Server能否性能正确，能否能够ping通，假设能，apt-get update运转成功