尽管为了提高VM启动性能，可以采取静态固定IP的方式来取代DHCP，但私有云当中还是有些环境依旧保留有DHCP方式，在并发进行云主机生命周期的时候，偶尔出现有未正常分配IP地址的情况，这部分需要好好分析下
这里说的涉及到DHCP的问题，首先主机这边应该能够查询到对应PORT的IP地址，但是在虚拟机内部，网卡的IP地址却为空，此时分析的大概流程如下
1：dhclient获取一次，通过dhclient -v $nic
2：如果dhclient获取失败，这时候继续发请求，在节点机上通过抓包工具抓取对应tap设备67端口的包，关注MAC地址
3：如果抓包只有request，却没有reply，可以查下对应的network，以及其对应的dhcp-agent节点是否都正常
4：如果都正常，那么就登陆到dhcp-agent节点上，进入namespace，在这边抓67端口的包，这里namespace和router类似，只不过是dhcp port
$ sudo ip netns exec qdhcp-$network_id ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
61: tap94fbda2b-73: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether fa:16:3e:03:c0:36 brd ff:ff:ff:ff:ff:ff
inet 10.180.65.235/23 brd 10.180.65.255 scope global tap94fbda2b-73
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe03:c036/64 scope link
valid_lft forever preferred_lft forever
抓个包瞧瞧
$ sudo ip netns exec qdhcp-$network_id tcpdump -i tap94fbda2b-73 port 67 -en tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap94fbda2b-73, link-type EN10MB (Ethernet), capture size 65535 bytes ^C
5：如果这时候还是没有reply的包，那么还是在dhcp-agent节点上，查看network进程
$ ps aux | grep $network_id
进程参数里查找一个文件的关键字
--dhcp-hostsfile=/data/neutron/dhcp/$network_id/host
然后在这个文件当中检索MAC地址，查找有无release等信息，以及和IP地址的对应关系
6：如果现在还没找到问题，就在dhcp-agent节点机上，查看/var/log/syslog日志
到现在，我就技穷了
今天就碰到了，最后通过重启dhcp-agent，问题就恢复正常了，不晓得哪位大神遇到过这个问题没~！
