Enligt rykten kommer VMware att släppa näste version av sin virtualiseringsplattform vSphere under andra halvan av 2011. Det påstås att vSphere 5 kommer att presenteras under VMworld senare i höst. Detta är ännu bara rykten så det finns inga garantier för detta. Hittade däremot lite uppgifter på vilka nyheter som eventuellt vSphere 5 kan komma att innehålla. Denna lista innehåller en hel del godsaker och det är bara att hoppas att denna information är så sanningsenligt som möjligt. Håll tillgodo!

What’s new in vSphere 5

• Build on the vSphere ESXi hypervisor architecture
• vSphere Auto Deploy combining host profiles, Image Builder and PXE
• Unified CLI framework, allowing consistency of authentication, roles and auditing.
• Support for up to 1 TB of memory
• Support for 32 vCPU’s per VM
• Nonhardware accelerated 3D graphics for Windows Aero support
• USB 3.0 device support
• UEFI virtual BIOS
• Host EUFI boot support
• New GUI to configure multicore vCPUs
• Client-connected USB devices
• Smart card reader support for VMs
• Apple Mac OS X Server 10.6 (Snow Leopard) guest OS support
• Support for up to 512 VMs
• Support for up to 160 Logical CPUs and 2 TB or RAM
• Improved SNMP support
• Storage driven storage delivery based on the VMware-Aware Storage APIs
• Improved version of the Cluster File System, VMFS5
• Accelerator for specific use with View (VDI) workloads, providing a read cache optimized for organizing, handling and deduplicating VDI client images.
• iSCSI user interface support
• Storage APIs – Array Integration: Thin Provisioning enabling reclaiming blocks of a thin provisioned LUN on the array when a virtual disk is deleted
• Swap to SSD
• 2TB+ LUN support
• Storage vMotion snapshot support
• vNetwork Distributed Switch improvements providing improved visibility in VM traffic
• ESXi Firewall protecting the ESXi 5.0 management interface
• A browser-based, fully-extensible, platform-independent implementation of the vSphere Client based on Adobe Flex.
• vCenter Server Appliance
• Inventory Extensibility: providing a manager to monitor partner extensions.
• vCenter Solutions Manager, providing a consistent interface to configure and monitor vCenter-integrated solutions developed by VMware and third parties.
• System message logging enhancements
• Revamped VMware High Availability (HA) with Fault Domain Manager
• All hosts in cluster can be primary nodes
• Cluster also uses shared storage as a channel for heartbeat detection

Bakgrund
Disk alignment är ett fenomen som många gånger förbises och som i virtualiseringssammanhang är extra viktigt att ha koll på då detta tillför ytterligare ett filsystemslager. För att klargöra det hela så börjar vi på SAN nivån. Den minsta beståndsdelen som används av lagrings-arrayen för att skapa ett LUN utav ett antal fysiska diskar kalls för ”chunk” eller ”stripe”.  På detta LUN skapas sedan en VMFS volym (i VMware miljöer) som delas upp i olika block. Det sista lagret är själva VMDK filen som på en Windows server formateras i NTFS som även detta delar upp disken i block som sedan grupperas i ”cluster” (allokerings enheter).  NTFS lagret använder sig utav MBR (Master Boot Record) som innehåller partitionstabellen.

Utrymmet mellan MBR som alltid ligger först på volymen och startpartitionen som utgör själva lagringsytan kallas för ”Offset” eller ”StartOffset”. Och det är storleken på detta utrymme  som är nyckeln till det hela och som skall justeras för att alla lager ska ligga i fas med varandra. Om samtliga lager inte ligger i fas med varandra kan diskprestandan bli lidande då onödigt många I/O operationer måste utföras för att läsa eller skriva data. Det här låter kanske krångligt men om vi tittar på animationen nedan så kanske det förklarar en del.

Problemet
Som vi ser i animationen så krävs det i värsta fall läsning av totalt 3 stycken ”chunks” från LUN:et när det egentligen hade varit tillräckligt med endast 1. Anledningen till detta är att både VMFS partitionen och NTFS partitionen är ur fas och ej i linje med underliggande chunksize (stripesize) på LUN:et. Detta innebär naturligtvis en prestandaförlust då antalet ”chunks” som måste bearbetas vid läsningar och skrivningar till och från disk blir onödigt många. I väldigt I/O intensiva miljöer som exempelvis databasservrar kan detta få betydande negativ inverkan på diskprestanda vad avser latency och throughput.

I ovanstående exempel är även VMFS partitionen ur fas med underliggande LUN. Detta är med aktuella versioner av ESX inte något problem då VMFS volymer som skapas med vSphere klienten (vilket för övrigt är en rekommendation från VMware) automatiskt får korrekt offset.  Problemet ligger oftast i det översta lagret som i detta exempel är en Windows formaterad NFTS partition med felaktigt offset.

Windows
Med Windows Server 2003 och tidigare versioner så skapas alla diskar som standard med en offset på 31,5KB för startpartitionen vilket gör att de inte är i fas med de underliggande ”chunk” storlekar som är vanligats på dagen lagrings arrayer (64K, 128K, 256K). Anledningen till detta är att tidiga versioner av BIOS använde sig utav cylindrar, huvuden och sektorer för adressering istället för LBA (Logical Block Adressing).  Senare versioner av Windows (Vista, W7 och server 2008) skapar automatiskt en korrekt offset och därmed är detta inget problem med aktuella versioner av Windows.

Kontollera dina partitioner
Hur gör man då om man vill kontrollera sina partitioner för att veta om de är ”alignade” (ursäkta svengelskan)? Det finns tredjepartsverktyg  och även powershell script som kan köras som kan identifiera detta. Men det enklaset sättet att kontrollera detta på en specifik windows VM är att använda sig utav kommandorads verktyget diskpart.exe

Följande bild visar hur du i Windows kontrollerar om en partition är korrekt riktad (i fas, i linje).

Som ni ser så visar diskpart här att startpartitionen har en offset på 32KB. Detta innebär att den inte är korrekt alignad dvs inte är i fas med underliggande disksystem. Jag nämnde ju tidigare att alla partitioner i Windows 2003 och tidigare versioner alltid alignar sina partitioner med en offset på 31,5KB. Men här ser vi istället värdet 32KB?! Borde inte detta innebära att denna partition är korrekt alignad då 32KB är jämnt delbart med 8 (vi kommer till detta senare) ?. Nja, så här ligger det till. Diskpart avrundar värdet 31,5KB (32,256 bytes) till 32KB (32768 bytes) vilket kan vara lite lurigt om man inte är medveten om detta. Om disken hade varit alignad ska diskpart visa en offset på 64KB. Detta är vad som rekommenderas.

För att vara på den säkra sidan kan man köra följande kommando för att kontrollera ”StartingOffset”

”wmic partition get BlockSize, StartingOffset, Name, Index”

Och som ni ser så är alltså denna partition unaligned då vi ser att StartingOffset är 32256 bytes.

Rekommendationer
För att säkerhetsställa att dina VMFS partitioner är i fas med chunk storleken på ditt SAN se då till att alltid använda dig utav vSphere klienten när du skapar dina VMFS partitioner då de automatiskt får rätt alignment (128KB).

För att säkerhetsställa att dina NFTS partitioner i Windows är i fas med det underliggande disksystemet (VMFS partitioner) så ska man inte använda ”Windows Disk Manager” för att skapa sina partitioner utan istället använda sig utav kommandorads verktyget diskpart.exe

Vmware rekommenderar att man sätter en offset för sin start partition som är en multipel av 8.

Microsoft rekommenderar att man sätter en offset på 64KB för startpartitionen.

Dessa rekommendationer förutsätter att inget annat uttryckligen har rekommenderats av tillverkaren för disksystemet.

Prestanda
Kommer inte att gå in i detalj på I/O, latency, throughput, RAID, etc i olika konfigurationer utan bara konstatera att det finns i många fall finns stora prestandavinster att göra genom att se till att sina partitioner är korrekt alignade. Hittade följande bild från Microsoft som talat ett tydligt språk.

Här kan vi tydliga prestandaskillnader mellan alignade och icke alignade diskar. Om vi tittar lite närmare så ser vi att vi har lika bra om inte bättre prestanda med 6st korrekt alignade diskar än med 8st icke alignade. Även fast vi har exakt likadana diskar med samma RAID konfiguration!

Lösning
Hur skapar man då en korrekt alignad partition i Windows? Jo, man använder sig som sagt var utav programmet diskpart. Följande bild visar steg för steg hur man skapar och alignar en partition på disk 1 med en offset på 64KB.

VMware rekommenderar dessutom att du formaterar din partition med en klusterstorlek på 32KB enligt bilden nedan. Observera att detta värde inte har någonting med alignment att göra. Vill man göra detta direkt med diskpart skriver man följande:

”format fs=ntfs unit=32K”

Systempartitionen
Hur fungerar det med alignment av systempartitionen då? Man har tyvärr ingen möjlighet att via Windows installationsprogram eller i efterhand konfigurera en korrekt offset på 64Kb med diskpart. Det som beskrivits ovan kan alltså enbart tillämpas på en datadisk som inte innehåller windows systemet. Detta innebär att om du tilldelar din VM en disk på ex 20GB och kör Windows installationsprogram så kommer denna systemdisk inte att vara korrekt alignad. Man bör alltså se till att ha en alignad systempartition klar innan man startar sin Windows installation då detta i efterhand är betydligt mer komplicerat.

Aligna systempartitionen INNAN Windows installationen
Hur gör man då för att för att aligna sin systempartition innan man installerar Windows? Det enklaste sättet är att använda sig utav en en annan VM och till denna skapa en ny disk som sedan kommer att användas som systemdisk till den ursprungliga maskinen. Låt mig klargöra detta lite närmare. Säg att vi vill skapa en ny VM som vi kallar VM-SRV2. På denna VM ska vi installera Windows Server 2003 på. För att kunna aligna denna systemdisk innan vi startar Windows installationen kan man använda sig utav en befintlig VM som vi här kallar för VM-SRV1. Följande steg ger dig en korrekt alignad systemdisk som du kan använda för VM-SRV2.

1. Addera en ny disk till VM-SRV1 och ange den storlek som du vill att VM-SRV2 skall ha som systemdisk.
2. Aligna sedan denna disk med diskpart och sätt en offset på 64KB enligt tidigare instruktioner.
3. Formatera sedan disken och välj en kluster storlek på 32KB.
4. Koppla sedan bort denna disk från VM-SRV1. Observera att du inte skall välja ”Remove from virtual machine” och inte ”Remove from virtual machine and delete files from disk”
5. Ta sedan bort redan befintlig systemdisk från VM-SRV2 genom att välja ”Remove from virtual machine and delete files from disk”
6. Välj sedan att lägga till en ny disk för VM-SRV2 och istället för att skapa en ny disk så väljer du ”Use an existing virtual disk” och pekar sedan på den disk som du skapade i steg 1
7. Nu har du en korrekt alignad systempartition på din disk och du kan nu starta windows installationen.

Tänk på att inte radera den befintliga partitionen som windows installationen kommer att hitta. Utan istället välja att enbart installera windows på denna partition utan att formatera om den. Detta för att säkerhetställa att din alignment och kluster storlek inte raderas.

Om man vill kan man mellan steg 5 0ch 6 välja att manuellt flytta den VMDK fil som utgör systemdisken till samma mapp som VM-SRV2 ligger för att få det hela mer organiserat.

Aligna systempartitionen EFTER Windows installationen
För att aligna en redan befintlig windows partition i efterhand kan man inte använda sig utav diskpart och den metod som jag beskrivit tidigare. En sådan operation är ett komplicerat ingrepp och kräver tredjeparts program som exempelvis:

vOptimizer Pro
Paragon Alignment Tool
GParted

Detta är som sagt ett stort ingrepp som kan innebära vissa risker och eventuella dataförluster. Jag rekommenderar därför att man absolut ser till att ha en aktuell backup innan en sådan operation utförs. Dessutom kanske man kan fråga sig om en alignment av just systemdisken kommer att tillföra så mycket vad avser prestandavinster. Är det verkligen värt mödan? Många gånger så är ju systemdisken där windows huserar inte så hårt belastad vad avser I/O som exempelvis en datadisk som innehåller databasfiler och transaktionsloggar är. I sådana fall finns det betydligt mer prestanda att vinna genom alignment. Allt detta bör alltså övervägas innan man fattar ett sådant beslut.

Referenser
VMware – Recommendations for Aligning VMFS Partitions
Yellow-Bricks – Aligning your VMs virtual hard disks
Microsoft – Disk Partition Alignment Best Practices

Själva konverteringen gick bra trots att det tog ca 5-6 timmar. Det var ca 150GB data som skulle migreras. Det tog lite tid då det bara var 100Mbit nät plus att det var riktigt slöa IDE-diskar. Efter att konverteringen var klar så skulle jag boota upp den nya virtuella maskinen. Detta lyckades INTE och jag fick bara meddelandet ”No operation system found”. Funderade lite kring detta och testade att mounta den VMDK fil som min nya virtuella maskin bestod av till en annan virtuell maskin för att kontrollera innehållet på denna. All data fanns där och jag redigerade ”boot.ini” för att va säker på att den gick mot rätt partition. Testade även att boota maskinen med en win srv 2003 skiva och körde FIXBOOT & FIXMBR utan resultat. Kollade även i diskmanagern att partitionen var aktiv.

Hyffsat frustrerad så började jag googla på detta då jag var ganska säker på att felet hade att göra med att det var en mjukvaruspegling på diskarna när konverteringen kördes. Det jag fann som besvarade min fundering och förklarade problemet var att VMware Convertern bara fungerar med basic eller dynamiska diskar. Men den dynamiska disken måste bestå av endast en fysisk disk.  Det man alltså måste göra innan konverteringen kan ske är att bryta speglingen på dessa diskar i diskmanagern (”break mirror”).

Convertern fungerar så att den försöker att skapa samma antal virtuella diskar som den hittar fysiska diskar under konverteringsprocessen. Detta innebär att diskarna måste ha unika enhetsnamn tilldelade. Om samma enhetsnamn (ex c:) delas mellan två fysiska diskar som är fallet med Windows mjukvaruraid så kommer konverteringen inte att fungera! Eller jo, den kommer att slutförs men det resulterar i att man inte har en bootbar volym.  Hårdvaruraid fungerar av dessa skäl naturligtvis bra. Något att tänka på om ni stöter på en maskin med mjukvaruraid som skall migreras till den virtuella världen.

Det har skett förbättringar och nyheter på följande områden:

• Windows 7 and Windows 2008 R2 support
• Enhanced Clustering Support for Microsoft Windows
• Enhanced VMware Paravirtualized SCSI Support
• Improved vNetwork Distributed Switch Performance
• Increase in vCPU per Core Limit
• Enablement of Intel Xeon Processor 3400 Series

För er som vill fördjupa er i vad detta i detalj innebär hittar ni mer information här:

http://www.vmware.com/support/vsphere4/doc/vsp_esxi40_u1_rel_notes.html

Vet även att Samsung har en 19″ LCD med Teradicis PCoIP chip inbyggt vilket innebär inte ens behöver ha en tunn klient för att kunna köra din ”high-end” desktop i en VDI lösning! Kommer att återkomma med mer info kring detta så fort jag fått möjlighet att sätta upp en labb-miljö och testa dessa funktioner fullt ut. Fram tills dess tycker jag att ni ska kika på denna video från årets VMworld där PCoIP demonstreras.

Det kommer att handla om de situationer jag stöter på under mitt dagliga arbete och de erfarenheter jag samlar på mig. Kommer även att ta upp lite nyheter runt virtualisering i allmänt och försöka ge er läsare lite praktiska tips som kan vara användbara i en virtualiserad miljö. Kommer mestadels att fokusera på produkter från VMware då detta är den leverantör av virtualiseringslösningar jag aktivt jobbar med och valt att fördjupa mig i.

Det som skrivs här kommer inte alltid att vara rena fakta eller konkreta synpunkter utan kanske snarare funderingar och reflektioner kring ämnet där frågan lämnas öppen för er läsare att föra diskussionen vidare. Uppmuntrar er att komma med åsikter och synpunkter både på det innehåll som publiceras samt det som önskas finnas med. Hoppas på en trevlig och intressant tid framöver på virtualisera.se så väl för mig som för er läsare.

Väl mött!