Документировано ли где-нибудь, что добавление диска к виртуальной машине Azure вызывает безусловную перезагрузку?

Я заметил, что добавление нового диска к виртуальной машине Ubuntu 14.04, работающей в Azure, вызвало безусловную перезагрузку Azure ВМ.

Когда я добавил второй диск, виртуальная машина не была перезагружена, но первый диск был украден, и мне нужно было перезагрузить виртуальную машину, чтобы восстановить доступ к первому диску.

Это не кажется особенно полезным поведением.

Это поведение где-нибудь задокументировано?

Обновлено: Изменено с добавлением дополнительных деталей, запрошенных в комментариях.

Процедура, которую я использовал для подключения нового диска, была скопирована в основном отсюда:

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

с некоторыми отличиями.

Эта процедура ниже описывает, что я сделал для добавления второго дополнительного диска (sdd). На прошлой неделе я сделал нечто подобное, чтобы добавить первый дополнительный диск (sdc). В этом случае система перезагружалась сама. В этом случае система не перезагружалась, но я потерял доступ к / dev / sdc, как только добавил новый диск.

Обратите внимание, что я не использовал Azure cli для выделения или подключения нового диска. Скорее я использовал веб-портал.

Сделав это, я использовал:

dmesg | grep scsi

, чтобы узнать, что новое устройство называется / dev / sdd

16 декабря 14:00:58 лазурное ядро: [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

Я читал эти сообщения так, что подсистеме SCSI в Ubuntu 14.04 не нравится все, что делает Azure для объявления о новых дисках, и, по сути, она теряет отслеживание уже подключенных дисков.

Другие примечания:

• ранее добавленный дисковый sdc не отображался в blkid до следующей перезагрузки
• после перезагрузки, / dev / sdc снова можно было использовать (хотя, конечно, это должно было быть fsck'd и базы данных на нем сохранились так же, как и базы данных, когда диск извлекается без предупреждения)