☰

是否有任何记录表明向 Azure VM 添加磁盘会导致无条件重启？

tag-icon • tag-icon linux hard-drive virtual-machines azure
是否有任何记录表明向 Azure VM 添加磁盘会导致无条件重启？

我注意到，向在 Azure 上运行的 Ubuntu 14.04 VM 添加新磁盘会导致 Azure VM 无条件重启。

当我添加第二个磁盘时，虚拟机没有重新启动，但是第一个磁盘被偷了，我需要重新启动虚拟机才能重新获得对第一个磁盘的访问权限。

这看起来并不是特别有帮助的行为。

这种行为有记录吗？

更新：已根据评论中要求的补充细节进行了修改。

我用来连接新磁盘的过程基本上是从这里抄袭的：

https://azure.microsoft.com/nl-nl/documentation/articles/virtual-machines-linux-how-to-attach-disk/

但有一些差异。

下面的步骤描述了我如何添加第二个额外磁盘 (sdd)。上周我做了类似的事情来添加第一个额外磁盘 (sdc)。在那个情况下，系统自行重启。在本例中，系统没有自行重启，但我确实在添加新磁盘后立即失去了对 /dev/sdc 的访问权限。

请注意，我没有使用 azure cli 来分配或连接新磁盘。相反，我使用了 Web 门户。

完成此操作后，我便使用：

dmesg | grep scsi

发现新设备名为 /dev/sdd

12 月 16 日 14:00:58 azure 内核：[2.696851] sd 5:0:0:1：[sdd] 已连接 SCSI 磁盘

然后我按照上述文章中的说明，使用 fdisk 格式化磁盘。

然后我挂载了磁盘并继续 rsync 将要移动到磁盘上的文件系统树。

就在那时，我注意到我上周连接的上一个磁盘 (sdc)（导致重新启动的磁盘）不再可访问。（它在 blkid 中也不可见）。

此后，我在 kern.log 中发现了这些消息，它们表明，在我完成门户中的连接磁盘操作后，（sdc）几乎立即变得无法访问（例如，在我通过扫描 dmesg 发现新磁盘之前）

Dec 16 13:23:34 azure kernel: [538544.870108] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:34 azure kernel: [538544.870267] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538545.824751] hv_storvsc vmbus_0_16: cmd 0x2a scsi status 0x0 srb status 0x20
Dec 16 13:23:35 azure kernel: [538545.824846] end_request: I/O error, dev sdc, sector 130548832
Dec 16 13:23:35 azure kernel: [538545.828189] Aborting journal on device sdc1-8.
Dec 16 13:23:35 azure kernel: [538545.830301] JBD2: Error -5 detected when updating journal superblock for sdc1-8.
Dec 16 13:23:35 azure kernel: [538545.836606] end_request: I/O error, dev sdc, sector 0
Dec 16 13:23:35 azure kernel: [538546.308389] sd 5:0:0:0: [sdc] Synchronizing SCSI cache
Dec 16 13:23:35 azure kernel: [538546.308528] hv_storvsc vmbus_0_16: cmd 0x35 scsi status 0x0 srb status 0x20
Dec 16 13:23:35 azure kernel: [538546.309513] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.309776] scsi 5:0:0:1: Direct-Access     Msft     Virtual Disk     1.0  PQ: 0 ANSI: 4
Dec 16 13:23:35 azure kernel: [538546.310764] sd 5:0:0:1: Attached scsi generic sg2 type 0
Dec 16 13:23:35 azure kernel: [538546.311251] sd 5:0:0:1: [sdd] 268435456 512-byte logical blocks: (137 GB/128 GiB)
Dec 16 13:23:35 azure kernel: [538546.311254] sd 5:0:0:1: [sdd] 4096-byte physical blocks
Dec 16 13:23:35 azure kernel: [538546.311265] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.312429] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.312737] scsi scan: INQUIRY result too short (5), using 36
Dec 16 13:23:35 azure kernel: [538546.313289] sd 5:0:0:1: [sdd] Write Protect is off
Dec 16 13:23:35 azure kernel: [538546.313293] sd 5:0:0:1: [sdd] Mode Sense: 0f 00 10 00
Dec 16 13:23:35 azure kernel: [538546.313750] sd 5:0:0:1: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA
Dec 16 13:23:35 azure kernel: [538546.326335]  sdd: unknown partition table
Dec 16 13:23:35 azure kernel: [538546.328228] sd 5:0:0:1: [sdd] Attached SCSI disk
Dec 16 13:23:35 azure kernel: [538546.446399] hv_storvsc vmbus_0_16: cmd 0x85 scsi status 0x2 srb status 0x86
Dec 16 13:23:35 azure kernel: [538546.446404] hv_storvsc vmbus_0_16: stor pkt ffff880159d31180 autosense data valid - len 18
Dec 16 13:23:35 azure kernel: [538546.446406] storvsc: Sense Key : Illegal Request [current] 
Dec 16 13:23:35 azure kernel: [538546.446409] storvsc: Add. Sense: Invalid command operation code
Dec 16 13:23:35 azure kernel: [538546.446495] hv_storvsc vmbus_0_16: cmd 0x85 scsi status 0x2 srb status 0x86
Dec 16 13:23:35 azure kernel: [538546.446498] hv_storvsc vmbus_0_16: stor pkt ffff880159d31180 autosense data valid - len 18
Dec 16 13:23:35 azure kernel: [538546.446499] storvsc: Sense Key : Illegal Request [current] 
Dec 16 13:23:35 azure kernel: [538546.446501] storvsc: Add. Sense: Invalid command operation code

我理解这些消息的原因是，Ubuntu 14.04 中的 SCSI 子系统不喜欢 Azure 为宣布新磁盘所做的一切，事实上，它会丢失已连接的磁盘的跟踪。

其他说明：

  • 之前添加的磁盘 sdc 直到下次重启后才出现在 blkid 中
  • 重启后，/dev/sdc 就可以再次使用了（当然，它必须经过 fsck 并且其上的数据库能够存活下来，就像磁盘在没有任何警告的情况下被撕掉时数据库也能存活一样）

答案1

在向正在运行的主机添加磁盘时，VM 重新启动 +1...向 22 台主机添加了 22 个磁盘，大约有一半重新启动或进入卡住状态，必须强制重新启动。

uname -a 3.10.0-123.13.2.el7.x86_64 #1 SMP 星期四 Dec 18 14:09:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux waagent --版本 WALinuxAgent-2.0.14 在 centos 上运行

Openlogic CentOS 7.1

想要添加更新，微软建议升级内核 + walinuxagent 来解决这个问题。它们会自动升级驱动程序库，这会导致与之前的内核版本不稳定。

来自 Microsoft 支持代表的消息：7.1 的最新内核升级是 kernel.x86_64 3.10.0-327.4.4.el7 这将更新 LIS 驱动程序。Hyper-V 和 Azure 的 Linux 集成服务 (LIS) 驱动程序是 Microsoft 直接贡献给上游 Linux 内核的内核模块。到目前为止，我们尚未遇到最新版本的任何问题。因此，我建议（在为您的应用程序测试后）更新内核以及 LIS 驱动程序。

答案2

只是想补充一下，我也遇到过这种情况。似乎仅仅向 Azure VM 添加磁盘就会导致其在没有任何警告的情况下重新启动。事实上，它可能会导致多个 VM 同时重新启动。

就我的情况而言，我使用 Azure Web 门户向特定 VM 添加单个磁盘，但在没有任何警告的情况下，VM 重新启动。这次重新启动导致站点中断。

我尝试搜索任何文档来解释为什么会这样，但一无所获。而且不可能获得 Azure 支持来提供帮助，因为……显然你必须付额外的钱（购买技术支持）来帮助你解决技术问题——即使是那些由 Azure 本身引起的问题。

如果可以，请尽量避免使用 Azure 作为关键的在线业务基础设施。

相关内容