ESXi ortamında EFI ürün yazılımı ve GPT önyükleme disklerini kullanmanın kayda değer avantajları (veya dezavantajları) var mı?


10

Temel sorum şu; başlıkta da belirtildiği gibi: EFI ürün yazılımı ve GPT önyükleme disklerini bir ESXi ortamında kullanmanın kayda değer avantajları (veya dezavantajları) var mı? "Dikkat çekici" ile, MBR diskler için iyi bilinen 2 TB sınırı ve BIOS önyükleme ürün yazılımının önyüklemek için MBR diskleri kullanması gereken kısıtlama dışında bir şey kastediyorum.

Belirli VM seçeneği aşağıdaki ekran görüntüsünde bulunmaktadır.

resim açıklamasını buraya girin

Bir fark yaratırsa, genel ortamımın yanı sıra özel olarak veya yalnızca bir Windows ortamıyla ilgili olan herhangi bir şeyle ilgilenmeme rağmen, belirli ortamımla ilgili bazı arka plan ve özellikler aşağıdadır.


Son on yılda $ [day_job] 'daki kurumsal derebelerimi sürüklemeyi başardığım bazı projeler sonucunda ev ofis sistemlerimizin çoğunu değiştireceğim. Bu sistemler ve bunların yerine geçecekleri temel olarak ESX 5.5'te sanallaştırılmış Windows Server OS'lerdir (şimdi güncelleme 1, yakında güncelleme 2 ve VMFS5, bu yüzden büyük hacimli destek). VM'ler ve eriştikleri tüm depolama birimleri, ESXi ana bilgisayarlarına NFS paylaşımları üzerinden sunulan bir SAN (EMC VNX 5400) üzerindedir. Her şey ince ayarlıdır.

Çoğunlukla, bir grup büyük, karmaşık PITA sistemini daha yeni platformlara yükseltecağım - örneğin, şu anda Server 2003 R2'de çalışan ve DFS kullanmayan çoklu TB dosya sunucularımız Sunucuya yükseltilecek 2012 R2, DFS ad alanlarına konabilir, DFS çoğaltmasını kullanabilir ve Server 2012 Veri Tekilleştirme kullanmaya başlayabilirsiniz. Şu anda Server 2003 R2 ve SQL Server 2005 üzerinde çalışan SharePoint sistemimiz, Server 2012 R2 çalıştıran SharePoint 2013'e yükseltilecek ve 2008 R2 veya üzeri bir SQL Server motoruna yüklenecektir. Ve bunun gibi.

Dosya sunucularına ve bunların üzerindeki veri miktarıyla nasıl başa çıkacağımıza bakarken (ev ofis dosya sunucularımızın her birinde 2 TB'tan fazla veri var), Sunucudaki Veri Tekilleştirme özelliğine baktım ve yerleştim 2012. Bu, birim başına çalıştığından, tüm verilerin mevcut karışıklığımız gibi birden çok cilde bölünmek yerine bir birim olması durumunda en iyi sonucu verir. Bu, GPT disklerinin veri birimlerimiz için en iyi olduğu konusunu gündeme getirdi ve beni EFI ve BIOS ürün yazılımı sorununa getirdi. Sunucularımızın tümü, herhangi bir veri biriminden ayrı 50 GB'lik OS [sanal] disklere sahiptir ve en azından şu anda bu şekilde tutmayı planlıyorum - yeni bir VM'ye veri birimi ekleyebilmek oldukça yararlı .

Dolayısıyla, bunu göz önünde bulundurarak, 2 TB MBR disk sınırını aştığı için GPT'ye ihtiyaç duyulan bir birimden önyükleme yapmamızı gerektiren bir senaryo öngöremiyorum. Ortamın tamamen sanal olması, GPT disklerinin kurtarılabilirlik avantajlarını ortadan kaldırıyor gibi görünüyor, bu yüzden yeni VM'lerimizi EFI önyükleme ürün yazılımı ve / veya GPT önyükleme birimleri ile oluşturmaya başlamak için zorlayıcı bir neden bulamıyorum. Tabii ki, BIOS önyükleme ürün yazılımı ve MBR disklerine sadık kalmak için zorlayıcı nedenler de bulamıyorum ve dolayısıyla sorum:

ESXi ortamında EFI ürün yazılımı ve GPT önyükleme disklerini kullanmanın kayda değer avantajları (veya dezavantajları) var mı? ("Dikkat çekici" ile, MBR diskler için iyi bilinen 2 TB sınırı ve BIOS önyükleme ürün yazılımının önyükleme için MBR diskleri kullanması gereken kısıtlama dışında bir şey kastediyorum.)


İşte VMware'in kesin cevabı . MichelZ'in yukarıda alıntıladığı aynı VMware EFI ekibi geliştiricisi tarafından parlak, yetkili ve yazılmıştır.
judoman

Yanıtlar:


4

BIOS ve UEFI cephesinde şunlar var: https://communities.vmware.com/thread/464854

Sanal ürün yazılımını, özellikle de sanal EFI uygulamasını geliştirmekten sorumlu ekip üzerinde çalışıyorum.

EFI'nin varsayılan olmasını düşünmemiştik. VSphere 5.1 GA için zamanında düzeltmek için çok geç bir hata yaptığımızı fark ettik ve ilk hatanın sonuçları, EFI'nin varsayılan olarak, örneğin dokümantasyon olarak tasarlandığını varsaydığı diğer çeşitli yerlere yayıldığını fark ettik. ve teminatın serbest bırakılması.

Varsayılan olarak BIOS'a dönmek istemenin temel nedeni FT desteğinin olmamasıdır - FT ile uyumlu olmayacak varsayılan bir yapılandırma sağlamak istemedik. BIOS üzerinde çalışan ancak EFI'de başarısız olan az sayıda PCI Geçiş senaryosu ve ekosistemdeki BIOS için genellikle daha geniş destek (ikincil işletim sistemi dağıtım çözümleri, işletim sistemi kurtarma çözümleri, PXE önyükleme ortamları ve PXE sunucusu gibi) gibi ikincil nedenler vardır. destek, vb.

Hepsi bu kadar. VSphere 5.1 GA için zamanında temizleyemeyeceğimiz bir şekilde yayılan bir hataydı ve yaptığı karışıklığa neden olan en üzücü.

Tavsiyem: FT'ye ihtiyacınız yoksa, PCI Passthrough'u kullanmayacaksınız (veya PCI Passthrough yapılandırmanızın sanal EFI ile çalıştığını doğrulayabilirseniz) ve dağıtmak için diğer BIOS'a özgü araçlara çok az bağımlılık veya hiç bağımlılık yoksa veya işletim sisteminizi yönetmek, EFI Windows 2012 VM'leri kurmaktan çekinmeyin.


Welp, bunun için gitti. EFI ve GPT. Patlarsa seni suçlayacağım. :)
HopelessN00b

Herzaman @ HopelessN00b :)
MichelZ

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.