这样的想法来自于一个假设，如果网卡被禁用之后，用户该如何处理，Azure又该如何处理，对于设置在虚拟机中的禁用网卡选项是否还有存在的意义？通常情况下，点选了禁用网卡对于你和虚拟机来说就一下之抓瞎了，瞬间失去光明的感觉，你的远程连接就这样被自杀了。为了验证这样的自杀行为，也考验Azure的强大自我管理特性，笔者开始了验证。【后面还有彩蛋，欢迎阅读到结尾】
进行基础信息的收集
对于和网卡有关的属性我认为常见的有MAC物理地址，IP地址，DHCP服务器，DNS后缀，网卡适配器名称。其中MAC地址作为一种原始数据存在于网卡本身，而这个特性被很多防篡改软件和产品作为“唯一识别码”来说是相当的重要。
Figure 1自杀前拍照留念，我特地标记了物理地址以突出他的重要性
开始禁用虚拟机中唯一的一块网卡
禁用开始，远程连接终端，并出现开始尝试最多20次的链接数量，此时在Azure.com的管理界面里看到系统还是活着的，可以判断Azure使用的是另一种非网络行为（方式）进行虚拟机状态监控。
随后，我手动方式在Azure的管理界面中关闭（shutdown）了虚拟机，很快的管理界面提示虚拟机已关闭。
再次对虚拟机进行开机，同样在Azure的管理界面，选择界面下方的启动（Start）。
Figure 2启动刚刚手动关闭的虚拟机，不过系统会提示关机还在进行中，请稍后尝试。继续点击Start启动按钮，进行第二次启动，此时已经过去了1分钟。此状态表明Azure在后台正在进行着什么。
随着第二次启动的尝试，Aure已经能够识别可开机指令，并返回启动已完成。
Figure 3当看到圆角矩形内的CPU核数识别以及右下角启动OK的标记后，我尝试远程连接，此时已经过去了1.5分钟了
随后就是使用之前下载回来的rdp文件进行远程连接，很快的各种安全提示与警告之后，我顺利登陆到了刚刚禁用网卡的虚拟机，此时已经过去了2分钟。
再等待一些内容和信息的加载之后，系统已经可以使用了，此时已经过去了2.5分钟。
加上之前系统关机到第一次启动这些时间，系统重我点下禁用网卡之后到现在总共经过了7.5分钟，其中那神秘的5分钟就是见证此刻奇迹的基础。
揭秘奇迹的时刻
禁用后的网卡居然自己“活”了，在刚刚我们已经见证了奇迹，而此刻我们需要揭秘一下奇迹的背后。
此图Figure 4展示的是网卡禁用后重新启动并远程进入的虚拟机设备管理器与网卡适配器的截图。请勿在意网卡名称后的数字，如果没有他们我是不会这么大胆撰写此文的，您只需要知道#2网卡是系统默认的那个，#3网卡是系统禁用后虚拟机重启自动分配的新网卡
Figure 4自杀后的设备管理器--网络适配器属性，因为是相同型号的网卡，虚拟机会对网卡进行由小到大数字、时间顺序的分配
让我们在验证一下那些关键网卡参数的变化
因为是第二次试验所以参照对象是#3网卡，也就是Figure 1里面所展示的那块网卡的属性。
Figure 5在此看到MAC是没有变化的——这太安心了，绿色高亮的是进行了变化且较为关键的网卡参数信息
小结：
通过上面的假设与验证，事实上已经可以忽略曾经在现实机器中的种种尴尬，而Azure是一个称职尽责的管理员，那神秘的5分钟就解决了此次非常重大的失手操作，用户完全不用担心触动了那些底层带来的负面影响，强大的Azure可以帮助我们即可发现，并顺利解决。
彩蛋：
想必聪明的你已经发现了什么，为什么默认情况下的网卡标识数字是#2呢？原本的#1呢？
Figure 6此图红框标记的就是网卡#1，这个应该是Azure的虚拟机管理员所使用的一块网卡，其中还能看到一些来自于微软的内部信息。4、3、2分别代表设备管理器中看到的网卡序号，这些内容都完整的存在于注册表中了
-=EOB=-