Есть ли заметные преимущества (или недостатки) в использовании прошивки EFI и загрузочных дисков GPT в среде ESXi?


10

Мой основной вопрос, как следует из названия: есть ли заметные преимущества (или недостатки) в использовании прошивки EFI и загрузочных дисков GPT в среде ESXi? Под «примечательным» я подразумеваю что-либо кроме хорошо известного ограничения в 2 ТБ для MBR-дисков и ограничения, что для загрузки микропрограммы BIOS необходимо использовать MBR-диски для загрузки.

Конкретная опция VM находится на скриншоте ниже.

введите описание изображения здесь

В случае, если это что-то меняет, некоторые общие сведения и особенности моей конкретной среды приведены ниже, хотя меня интересует общий случай, а также все, что касается конкретно или только среды Windows.


В результате некоторых недавних проектов, в которых мне удалось перетащить своих корпоративных управляющих с $ [day_job] в текущее десятилетие, я заменю многие наши системы домашнего офиса. Эти системы, а также то, чем они должны быть заменены, в основном представляют собой ОС Windows Server, виртуализированные на ESX 5.5 (обновление 1 сейчас, скоро будет обновление 2, и VMFS5, поэтому поддержка большого объема). Виртуальные машины, а также все хранилища, к которым они обращаются, находятся в сети SAN (EMC VNX 5400), которая предоставляется хостам ESXi через общие ресурсы NFS. Все тонко обеспечено.

По большей части, я просто буду обновлять кучу больших, сложных систем PITA на более новые платформы - например, наши мульти-ТБ файловые серверы, которые в настоящее время работают на Server 2003 R2 и не используют DFS, будут обновлены до Server 2012 R2, поместите его в пространства имен DFS, используйте репликацию DFS и начните использовать дедупликацию данных Server 2012. Наша система SharePoint, которая в настоящее время работает на Server 2003 R2 и SQL Server 2005, будет обновлена ​​до SharePoint 2013 с Server 2012 R2 и установлена ​​на ядро ​​SQL Server 2008 R2 или выше. И так далее.

Рассматривая файловые серверы и методы работы с объемом данных на них (на каждом из файловых серверов нашего домашнего офиса объем данных превышает 2 ТБ), я рассмотрел и остановился на функции дедупликации данных на сервере. 2012. Поскольку это работает для каждого тома, лучше всего работать, если все данные одного тома, а не разделены на несколько томов, как в нашем текущем беспорядке. Это подняло вопрос о том, какие диски GPT лучше всего подходят для наших объемов данных, и привело меня к вопросу о прошивке EFI против BIOS. Все наши серверы имеют [виртуальные] диски объемом 50 ГБ, которые отделены от любых томов данных, и, по крайней мере, в настоящее время я планирую придерживаться этого - возможность подключения тома данных к новой виртуальной машине довольно полезна. ,

Поэтому, учитывая это, я не могу представить сценарий, в котором нам когда-либо понадобится или мы хотим, чтобы виртуальная машина загружалась с тома, который должен быть GPT, если объем диска MBR превышает 2 ТБ. Тот факт, что среда является чисто виртуальной, по-видимому, сводит на нет преимущества восстанавливаемости GPT-дисков, поэтому я не могу придумать никаких веских причин начать создавать наши новые виртуальные машины с загрузочной микропрограммой EFI и / или загрузочными томами GPT. Конечно, я также не могу придумать какие-либо веские причины придерживаться загрузочной прошивки BIOS и MBR-дисков, и, следовательно, мой вопрос:

Есть ли заметные преимущества (или недостатки) в использовании прошивки EFI и загрузочных дисков GPT в среде ESXi? (Под «примечательным» я подразумеваю что-либо кроме хорошо известного ограничения в 2 ТБ для MBR-дисков и ограничения, что для загрузки микропрограммы BIOS необходимо использовать MBR-диски для загрузки.)


Вот окончательный ответ VMware . Он великолепен, авторитетен и написан той же командой разработчиков VMware EFI, которую MichelZ цитирует выше.
дзюдоист

Ответы:


4

На фронте BIOS против UEFI есть это: https://communities.vmware.com/thread/464854

Я работаю в команде, ответственной за разработку виртуальной прошивки, в частности, виртуальной реализации EFI.

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

Основной причиной желания вернуться в BIOS по умолчанию является отсутствие поддержки FT. Мы не хотели предоставлять конфигурацию по умолчанию, которая будет несовместима с FT. Существуют вторичные причины, такие как небольшое количество сценариев PCI Passthrough, которые будут работать в BIOS, но не работают в EFI, и, как правило, более широкая поддержка BIOS в экосистеме, такие как решения для развертывания гостевых ОС, решения для восстановления ОС, загрузочные среды PXE и ​​PXE-сервер. поддержка и пр.

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

Мой совет: если вам не нужен FT, вы не будете использовать PCI Passthrough (или если вы сможете проверить, что ваша конфигурация PCI Passthrough работает с виртуальным EFI), и у вас мало или нет зависимостей от других специфичных для BIOS инструментов для развертывания или Управляя своей ОС, вы можете свободно развертывать виртуальные машины EFI Windows 2012.


Welp, пошел на это. EFI и GPT. Если он взорвется, я обвиню тебя. :)
HopelessN00b

В любое время @ HopelessN00b :)
MichelZ

1

Одним из мест, где настройка EFI для виртуальных машин очень полезна, является возможность ручного преобразования P2V для систем с «голым железом», которые были установлены с использованием EFI, поскольку EFI не поддерживается VMware Converter (или не было, как я последний раз проверял). См. Как выполнить преобразование P2V системы EFI Windows Server 2008 R2? для фона на это.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.