Есть ли какие-либо известные преимущества (или недостатки) к использованию встроенного микропрограммного обеспечения EFI и загрузочных дисков GPT в среде ESXI?
Мой основной вопрос, как просит заголовок: есть ли какие-либо известные преимущества (или недостатки) к использованию встроенного микропрограммного обеспечения EFI и загрузочных дисков GPT в среде ESXI? "Известным" я имею в виду что-либо кроме известного предела на 2 ТБ для дисков MBR и ограничение, от которого встроенное микропрограммное обеспечение начальной загрузки BIOS должно использовать диски MBR для начальной загрузки.
Определенная опция VM находится в снимке экрана ниже.
В случае, если это имеет значение, некоторый фон и специфические особенности моей конкретной среды ниже, хотя я интересуюсь общим случаем, а также чем-либо, что имело бы отношение конкретно или только к среде Windows.
В результате некоторых недавних проектов, где я преуспел в том, чтобы перетащить своих корпоративных повелителей на уровне $ [day_job] в текущее десятилетие, я буду заменять много наших систем домашнего офиса. Этими системами, а также чем они должны быть заменены, являются, прежде всего, Ose Windows Server, виртуализированные на ESX 5.5 (обновите 1 теперь, скоро чтобы быть обновлением 2, и VMFS5, таким образом, поддержка большого объема). VMs, а также все устройство хранения данных, к которому они получают доступ, находятся на SAN (EMC VNX 5400), который представлен хостам ESXI по долям NFS. Все тонко настраивается.
По большей части я буду просто обновлять набор больших, сложных, систем ЛАВАША на более новые платформы - например, наши файловые серверы мульти-ТБ, которые в настоящее время работают на Сервере 2 003 R2 и не используют DFS, будут обновлены до Сервера 2 012 R2, помещены в пространства имен DFS, использовать репликацию DFS и начать использовать Дедупликацию данных Сервера 2012 года. Наша система SharePoint, которая в настоящее время работает на Сервере 2 003 R2 и SQL Server 2005, будет обновлена до SharePoint 2013, выполняя Сервер 2 012 R2, и поставится механизм SQL Server 2 008 R2 или выше. И так далее.
В изучении файловых серверов, и как иметь дело с объемом данных по ним (каждый из наших файловых серверов домашнего офиса имеет данные сверх 2 ТБ), я изучил и обосновался на, функция Data Deduplication в Сервере 2012. Так как это работает на основе на объем, она работает лучше всего, если все данные являются одним объемом, вместо разделения через несколько объемов, как наша текущая путаница. Это подняло проблему дисков GPT, являющихся лучшим для наших объемов данных, и принесло мне к вопросу EFI по сравнению со встроенным микропрограммным обеспечением BIOS. Наши серверы у всех есть ОС [виртуальные] диски 50 ГБ, которые являются отдельными от любых объемов данных, и по крайней мере в настоящее время, я - планирование хранения его тот путь - способность присоединить объем данных к новому VM довольно полезна.
Так, имея это в виду, я не могу предположить сценарий, откуда мы когда-либо нуждались бы или хотели бы, чтобы VM загрузился объема, который должен быть GPT для того, чтобы быть по дисковому пределу MBR на 2 ТБ. То, что среда является чисто виртуальной, действительно кажется, инвертирует преимущества восстанавливаемости дисков GPT, таким образом, я не могу придумать неопровержимый довод, начинают создавать наш новый VMs со встроенным микропрограммным обеспечением начальной загрузки EFI и/или загрузочными томами GPT. Конечно, я также не могу придумать неопровержимые доводы, чтобы придерживаться встроенного микропрограммного обеспечения начальной загрузки BIOS и дисков MBR, и следовательно, мой вопрос:
Есть ли какие-либо известные преимущества (или недостатки) к использованию встроенного микропрограммного обеспечения EFI и загрузочных дисков GPT в среде ESXI? ("Известным" я имею в виду что-либо кроме известного предела на 2 ТБ для дисков MBR и ограничение, от которого встроенное микропрограммное обеспечение начальной загрузки BIOS должно использовать диски MBR для начальной загрузки.)
На передней панели 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.
Одно из мест, где настройка EFI для виртуальных машин очень полезна, - это разрешение ручного преобразования P2V систем без операционной системы, которые были установлены с использованием EFI, поскольку EFI является не поддерживается VMware Converter (или не поддерживается, в последний раз проверял). См. Как выполнить преобразование P2V в системе Windows Server 2008 R2 EFI? для получения справочной информации.