今天早上刚到公司，就发现研发环境的机器连不上了。

　　公司研发环境的部署比较简单，物理机上装VMware Esxi 6 ，然后在esxi上装虚机。

　　检查发现：esxi ping不通，客户端也连不上；物理机远程管理卡ping不通，ipmi管理客户端也连不上。

　　处理方法：五年前的机器了，远程管理卡都连不上了，一般就是服务器硬件出问题了。不去管它了，直接找别的机器再搭一套研发环境就是了。新研发环境机器数量用途不变，只是给四台机器换了下ip地址。见下图：

　　说干就干，装起来，机器装完之后开始部署服务，在部署调试的过程中发现部分机器特别卡，ssh上去之后敲命令都卡，一般都得等十几秒才能缓过来。

　　调查过程：

　　　　1、检测esxi物理机性能，未见异常

　　　　2、检测各虚拟机性能，未见异常

　　　　3、因为新的研发环境是两个人一起完成的，检测两个人历史操作记录和配置文件，未见异常

　　　　4、百度 esxi 虚拟机丢包 ，未果

　　　　5、检查同物理机上的原有虚机（物理机上部署新研发环境之前还有8台虚机），原有虚机没有发现丢包现象

　　　　6、写个脚本循环ping新研发环境的各个ip，发现上图中新使用的ip（绿色部分）一个包也不丢

　　　　7、对比试验，新建两台vm 10.12.30.61 和 10.12.30.62 ，进行ping测试，不丢包

　　　　8、给新建的两台vm 更改ip为原来用过的 10.12.30.7 和 10.12.30.8 ，进行测试，发现丢包现象

　　　　9、思考：ip冲突？老机器物理机都挂了，vm也连不上了，不可能互相抢ip啊！！！

　　　　10、验证9中的想法，当我循环ping的脚本报告 10.12.30.12 ping 失败的时候，开一个新的ssh会话，快速执行多次 arp -an ，见下图。还真是ip冲突了！！！！ 同一个IP地址，两次看到的mac地址不一样。老机器自己恢复了？

　　　　11、再次检查老机器 远程管理卡、物理机操作系统、虚机操作系统，依旧都连不上。但问题肯定出在老的机器上

　　　　12、验证11中的想法，由于远程管理卡都连不上了，我人有不在机房，那就只能去交换机上把老机器的接口shutdown了。在交换机上把老机器的接口shutdown后进行ping测试，一切正常，一个包都不丢了。

　　　　13、看来11中的想法是对的，其实也不是阴魂不散，机器宕机后，虽然好多服务都无法使用了，因为没有进行断电操作，有部分基础的服务仍运行在内存中，比如这次宕机后虽然物理机和虚机都ping不通也连不上了，但是还能进行arp应答，也算是比较顽强的了

　　总结经验教训：如果物理机被认定发生硬件故障无法继续使用了，一定要进行断电处理，同时也是为了机房其他服务器的安全和稳定

宕机不等于关机，阴魂不散的vm