https://www.jerryzone.cn/aliecs-ubuntu-losteth/

前几天阿里云给我来了封邮件，说我的主机上有漏洞，但是没有具体说明到底有什么漏洞，于是今天登陆进入后台准备看一下具体漏洞是啥。登陆到后台后发现一个坑爹的设定：必须开通安骑士才能看到具体的漏洞列表，不让看就算了。

然而，在站内信的通知里边发现了一个华北1地域云服务器预约迁移的通知，说机房升级，希望预约个时间，关机把ECS服务器转移到新的机房，并且会提供服务器配置的升级，而且还说十月一号是迁移的最后期限。反正现在主机上什么都没跑，处于空闲状态，就考虑现在迁过去得了，反正早晚的事情。于是预约在今天下午的13点整重启迁移。迁移很快，几分钟完事，阿里云就发来了成功的短信，也就没有关注它去睡午觉了。

午觉醒来，做了一些事情，在下午三点，突然发现服务器上跑的一个小服务处于了不可访问的状态，于是考虑是不是当时配置Nginx的时候忘记设置为系统自启服务，导致阿里云官方在重启机器后没有继续运行，准备连接SSH进入Shell手动启动Nginx。说来也怪，SSH也成了不可访问的状态，这就比较奇怪了，一般不动他或者正常重启后，最起码SSH是可用的状态，但是今天升级迁移之后SSH也不能用了，怀疑ECS服务器还有更严重的故障。通过阿里云控制台，成功登陆进入远程控制台，看到了云主机的画面，登陆进去后尝试手动启动Nginx。

当我尝试重启Nginx的时候，却提示无法解析一个反代的域名。这就比较奇怪了，因为是个外网的域名，考虑域名本身可能出问题，于是用nslookup尝试解析百度的域名，发现也不能解析。考虑是不是阿里云机房DNS故障了。当我刚刚要使用ifconfig查看网卡的DNS设置的时候，发现如下画面：

WTF？网卡没了？难道是阿里云搬主机把网卡搬丢了？不应该啊，这种问题应该不可能出现的说。遇到这种问题，自己也不方便修，毕竟大把大把的数据还在上边押着，不适合乱搞。于是求助客服，发了个工单，挂紧急维修请求。客服的速度倒是挺快，立即回复，请求给他服务器的认证凭证，我就给了他。然后后台工程师就没动静了直到下午五点半，后台工程师回复说因为用户私自将Ubuntu系统从阿里云默认的14.04升级到了16.04的版本，所以后台处理不了。。。

执行完成后出现:

稍等，网卡不是丢了了么，怎么又出来了？这里是因为网卡并不是真的被阿里云拔走了，而是在切换了运行环境后，和/etc/network/interface中的参数不对应了，导致Ubuntu因为没有这两块网卡的配置信息而无法启用这两个网卡。阿里云在迁移过程中理应考虑到这个问题，在查看了interface文件后，发现他确实考虑到这个问题了，只不过把配置文件中的逻辑名称改为了eth0和eth1这两个完全不存在的设备：

可以看得出来，eth0是那块和内网通信的网卡，eth1是那块和外网通信的网卡。考虑这两个网卡应该是之前看到的ens3和ens4，那么改过来试试咯。

然后保存直接在命令行使用reboot重启ECS服务器。这时候再次登录shell使用ifconfig查看网络设备的IP地址，发现已经多出来了两个ens3和ens4，说明两个设备已经正常工作了。

访问服务器上的网站，发现可以正常访问没有问题。
其实阿里云的ECS本身就是个虚拟机,而迁移只是将虚拟机从一台物理主机上拷到另一台物理主机上去运行,当迁移过后,系统自动打开磁盘的/dev/network/interface,根据约定好的ip等数据重新写入这些内容,而此时虚拟机是处于关机状态的,配置文件生成程序并不知道实际运行的时候网卡的逻辑名称到底是什么,而直接默认以14.04的规则,直接使用eth*的前两个作为两块网卡的逻辑名,而在16.04上这个命名规则是有变化的,导致最终启动后无法找到网卡.
在我们平时互相拷贝VMware的虚拟机过程中,也有可能会出现这种问题,即使没有这样一个程序自动的挂载虚拟硬盘改配置,但是存在因为拷贝导致实际的逻辑名和配置文件中的逻辑名匹配出现差错,导致Ubuntu找不到网卡.

这里我就想吐槽一句：难道阿里云的工程师就连这个都发现不了？