windows – 在ESXi环境中使用EFI固件和GPT引导磁盘有任何明显的优点(或缺点)吗?

前端之家收集整理的这篇文章主要介绍了windows – 在ESXi环境中使用EFI固件和GPT引导磁盘有任何明显的优点(或缺点)吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我的基本问题是,正如标题所示:在ESXi环境中使用EFI固件和GPT启动盘有任何明显的优点(或缺点)吗? “值得注意的是”,我指的是MBR磁盘众所周知的2 TB限制以及B IOS启动固件必须使用MBR磁盘启动的限制.

特定VM选项位于下面的屏幕截图中.

如果它有所不同,我的特定环境的一些背景和细节在下面,虽然我对一般情况以及与Windows环境或仅与Windows环境有关的任何内容感兴趣.

由于最近的一些项目,我已经成功地将我的公司领导者[$day_job]拖到了当前的十年,我将取代我们的许多家庭办公系统.这些系统以及它们将被替换的主要是在ESX 5.5上虚拟化的Windows Server操作系统(现在更新1,很快将更新2,VMFS5,因此需要大量支持).虚拟机及其访问的所有存储都位于SAN(EMC VNX 5400)上,该SAN通过NFS共享提供给ESXi主机.一切都是精简配置.

在大多数情况下,我只是将一堆庞大,复杂的PITA系统升级到更新的平台 – 例如,我们目前在Server 2003 R2上运行但不使用DFS的多TB文件服务器将升级到服务器2012 R2,放入DFS命名空间,利用DFS复制,并开始使用Server 2012 Data Deduplication.我们的SharePoint系统目前在Server 2003 R2和sql Server 2005上运行,将升级到SharePoint 2013,运行Server 2012 R2,并安装在2008 R2或更高版本的sql Server引擎上.等等.

在查看文件服务器,以及如何处理它们上的数据量(我们的每个家庭办公文件服务器的数据都超过2 TB)时,我调查并确定了服务器中的重复数据删除功能因为它适用于每个卷,所以如果所有数据都是一个卷,而不是像我们当前的混乱那样分割到多个卷,它最有效.这就提出了GPT磁盘最适合我们数据卷的问题,并引出了EFI与BIOS固件的问题.我们的服务器都有50 GB的操作系统[虚拟]磁盘,这些磁盘与任何数据卷都是分开的,至少在目前,我打算保持这种状态 – 能够将数据卷连接到新的VM是非常有用的.

因此,考虑到这一点,我无法想象我们需要或希望VM从需要GPT的卷启动超过2 TB MBR磁盘限制的情况.环境纯粹是虚拟的这一事实似乎否定了GPT磁盘的可恢复性优势,因此我无法提出任何令人信服的理由开始使用EFI启动固件和/或GPT启动卷构建新的VM.当然,我也无法提出任何令人信服的理由坚持使用BIOS启动固件和MBR磁盘,因此,我的问题是:

在ESXi环境中使用EFI固件和GPT引导磁盘有任何明显的优点(或缺点)吗? (“值得注意的是”,我指的是MBR磁盘的众所周知的2 TB限制以及BIOS启动固件必须使用MBR磁盘启动的限制.)

在BIOS vs UEFI前面,有这样的:
https://communities.vmware.com/thread/464854

I work on the team responsible for developing the virtual firmware,
specifically the virtual EFI implementation.

We had not intended that EFI be the default. We realized that we’d
made a mistake too late to correct it in time for vSphere 5.1 GA,and
the consequences of the initial mistake had propagated to varIoUs
other places which had now assumed that EFI was intended to be the
default,such as documentation and release collateral.

The primary reason for wanting to return to BIOS by default is the
lack of FT support – We did not wish to provide a default
configuration that was going to be incompatible with FT. Secondary
reasons exist,such as a small number of PCI Passthrough scenarios
which would work on BIOS but fail on EFI,and generally broader
support for BIOS in the ecosystem – such as guest OS deployment
solutions,OS recovery solutions,PXE boot environments and PXE server
support,and so forth.

That’s all there is to it. It was a mistake which propagated in a way
that we couldn’t clean up in time for vSphere 5.1 GA,and it’s most
regrettable that caused the confusion that it did.

My advice: If you don’t need FT,won’t be using PCI Passthrough (or if you can validate that your PCI Passthrough configuration works with virtual EFI),and have few or no dependencies on other BIOS-specific tools to deploy or manage your OS,you can feel free to deploy EFI Windows 2012 VMs.

猜你在找的Windows相关文章