Как ошибки физического диска выглядят для гостя VMware?

Предположим, у нас есть хранилище данных на локальном диске, и есть виртуальная машина с виртуальным жестким диском, .vmdk Файл находится в этом хранилище данных.

Обычно, если виртуальная машина пытается прочитать диск, например, она фактически читает блоки в .vmdk файл. Эти блоки, в свою очередь, должны быть прочитаны с локального диска, на котором находится хранилище данных. Таким образом, данные поступают с физического диска в систему VMFS ядра VMware, затем в гипервизор, который затем эмулирует контроллер SCSI, с которого читает гостевая ОС.

Но что произойдет, если физический диск скажет: "Ой, простите, этот сектор плохой".

Что ж, если этот сектор окажется частью метаданных VMFS, то что произойдет, будет зависеть от отказоустойчивости VMFS. Однако в этом случае предположим, что плохой сектор находится в пользовательских данных с точки зрения VMFS. Другими словами, VMFS структурно не повреждена, но данные для конкретного блока в .vmdk файл потерян.

Что видит гостевая ОС?

Я вижу две возможности. Первая возможность и то, как она будет работать, если я ее спроектирую, будет состоять в том, что VMware фактически скажет гостю, что чтение не работает. Это значит, что эмулируемый контроллер SCSI будет делать то же, что и контроллер SCSI, когда диск блокируется в секторе.

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

Это было бы довольно глупо, но я должен задаться вопросом. Мне интересно, что я получил такие диски в raidz ZFS в гостевой системе Solaris, и после переустановки я обнаружил, что один из моих дисков в гостевой машине показал:

NAME        STATE     READ WRITE CKSUM
...
    c7t4d0  ONLINE       0     0    19

Эти ошибки были исправлены с помощью данных четности с других дисков, поэтому в пуле нет ошибок данных, но я все еще хочу знать, что именно произошло.

Как я понимаю из вышеприведенного отчета, это означает, что c7t4d0 принудительно вернул сектор, полный данных, но данные были неверны, как определено криптографическим хэшем. Это случилось не один раз, а 19 раз! Я просто достаточно верю в коды Хэмминга, используемые производителями жестких дисков, чтобы заподозрить, что, хотя вы, возможно, и молчаливо развращаетесь в собачьем возрасте, получить 19 из них одновременно, как это астрономически маловероятно.

Мне кажется гораздо более вероятным, что коррупция на самом деле не была молчаливой - что жесткий диск фактически сказалVMware, что сектора не могут быть прочитаны, но что VMware отключился и просто заполнил их нулями или чем-то, что, конечно, приведет к ошибкам контрольной суммы в гостевой уровень. Я бы посчитал это довольно обременительной ошибкой! Вред мог бы быть весьма серьезным, если бы это была не файловая система, подобная ZFS, которая была бы достаточно умна, чтобы распознавать потерянные пользовательские данные.

Итак, мой вопрос: что именно делаетVMware в тех ситуациях, когда резервный физический диск выдает ошибки ввода-вывода? Приведенные выше доказательства, по-видимому, намекают на то, что они поступают неправильно, но я на самом деле не знаю.

Я понимаю, что вы обычно используете SCSI passthrough в этом конкретном приложении и что вы всегда получите ожидаемый результат в этом случае, но по причинам, в которые я не могу попасть, я не смог использовать passthrough в этом случае. В любом случае, я все еще ожидаю, что VMware поступит правильно.

Эта конкретная система установлена ​​на более старой версии VMware ESXi 5, но мне интересно, как это вообще делается, включая более новые версии.