今天早上刚到公司，就发现研发环境的机器连不上了。
公司研发环境的部署比较简单，物理机上装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应答，也算是比较顽强的了
总结经验教训：如果物理机被认定发生硬件故障无法继续使用了，一定要进行断电处理，同时也是为了机房其他服务器的安全和稳定