Virtuella förhållanden

Har sammanställt lite enkla riktlinjer gällande frågor som ofta dyker upp i virtualiserings sammanhang. Det kan vara frågor som:

  • Hur många virtuella maskiner kan jag köra på en host?
  • Hur stora LUNs skall jag skapa på mitt SAN?
  • Hur många VMs kan jag köra per LUN?
  • Hur mycket RAM och CPU skall jag ha i mina hostar?

Hostsize

Det finns naturligtvis inget enkelt svar på dessa frågor och egentligen inte något rätt och fel. Det är ju många faktorer och förhållanden som spelar in och avgör hur man i slutändan fattar ett beslut. När det gäller storleken och hur man skall dimensionera sina hostar när vi talar CPU och RAM så handlar det om att hitta ett lagom förhållande mellan den fysiska hårdvaran och den arbetslast som skall hostas på denna. Större och kraftfullare servrar innebär färre fysiska hostar att drifta och underhålla, men samtidigt medför detta att konsekvenserna av en eventuell serverkrasch blir allt mer allvarlig. Fördelen med fler mindre fysiska hostar är att lasten kan spridas ut på ett mer effektivt sätt och på så vis minimeras de negativa följderna vid ett hårdvarufel. Dessutom fungerar enligt min uppfattning lastbalanseringen (DRS) bättre i en mer balanserad miljö. I de flesta fall är det alltså bättre att skal ut än att skala upp. Oftast vill man ju ha inte belasta sina hostar mer än 70% för att tillgodose kraven för HA vilket på en kraftfullare maskin innebär större resurser som inte nyttjas. Ett exempel på lämplig server i denna klass skulle kunna vara en HP DL380 eller liknande.

pCPU vs vCPU

När vi sedan talar om förhållandet mellan den fysiska servern och de virtuella maskinerna, alltså hur många VMs / ESX host man kan köra så är svaret återigen ”det beror på”. I några fall när du har en mycket kraftfull host och de VMs som hostas har en mycket låg arbetsbelastning så kan man nå förhållanden på ca 60:1 medan du på en mindre kraftfull host och VMs med hög arbetslast kanske enbart når ett förhållande på 10:1 eller mindre. Man brukar generellt räkna med att en mellanklass server med 2 sockets kan nå ett förhållande på ca 16:1 och ca 32:1 för en med 4 sockets med en normal arbetslast på de VMs som hostas. Det gäller att ha koll på antalet virtuella CPUer i dessa sammanhang. Som en tumregel kan man räkna med att kunna köra 4 x vCPU x antalet pCPU. Det skulle på en server med två fysiska fyrakärninga CPUer ge oss 8pCPU x 4 = 32 vCPU.

Lagringdirektiv

För många VMs per LUN kan skapa flaskhalsar på ditt SAN och du kan få problem med metadata låsningar etc. Det är även viktigt att förhålla sig till det underliggande disksystemet och antalet spindlar i det RAID set som levererar lagringen. Här följer några riktlinjer att förhålla sig till:

  • Antalet VMs per LUN i genomsnitt: 14 to 16
  • För hög I/O belastning, applications: 8 to 10 VMs per LUN
  • För medel I/O belastning: 20 to 22 VMs per LUN
  • För mycket låg I/O belastning, terminalservrar, VDI-klienter: mer än 100 VMs per LUN

Tänk på att allt som föreslagits här endast är riktlinjer och rekommendationer. Det finns otaliga faktorer som spelar in i dessa sammanhang och det kan skilja mycket från olika miljöer. Det viktigaste är att man tänker till innan man designar sin virtuella infrastruktur för att på så vis slippa de vanligaste prestandaproblemen.

VM snapshots och VMFS blocksize

Upptäckte idag en ganska så intressant sak angående vSphere, snapshots och blockstorleken på VMFS volymer. Detta uppdagades i en miljö där jag skulle undersöka och försöka reda ut varför ett backupjobb skapat i Veeam Backup and Replication hade misslyckats. Jag började med att titta i loggen för det aktuella backupjobbet och den specifika virtuella maskinen i Veeam. Där meddelades följande orsak till varför jobbet misslyckats:

”Creating snapshot
CreateSnapshot failed, vmRef ”320″, timeout ”1800000″, snName ”VEEAM BACKUP TEMPORARY SNAPSHOT”, snDescription ”Please do not delete this snapshot. It is being used by Veeam Backup.”, memory ”False”, quiesce ”True”
A snapshot operation cannot be performed.”

Detta tyder på att backupjobbet som bygger på att en snapshot tas på aktuell VM inte lyckades med den uppgiften. Veeam Backup & Replication som för övrigt är ett strålande verktyg för backup, replikering och återställning hade lyckats att slutföra backupen för alla (ca 30 st) virtuella maskiner utom för just denna. För att hitta källan till detta testade jag att manuellt skapa en snapshot i vSphere klienten på denna VM och fick där följande felmeddelande:

snapshot_failed

Det var alltså inte möjligt att skapa en snapshot på denna VM trots att det fanns gott om utrymme på de VMFS volymer som den lagrades på. Hittade en KB artikel på VMware.com som förklarar fenomenet. Orsaken till detta är att storleken på en utav de virtuella diskarna för den aktuella maskinen överstiger den storlek som begränsas till ett fast värde beroende på vilken ”blocksize” som den VMFS volym har där den virtuella maskinens ”working directory” husgherar. Låter det klurigt? Jag håller med!

För att klargöra det hela så börjar vi med de storleksbegränsningar för filer som respektive blocksize utgör på en VMFS datastore

Block Size Maximum File Size
1 MB 256 GB – 512 Bytes
2 MB 512 GB – 512 Bytes
4 MB 1024 GB – 512 Bytes
8 MB 2048 GB – 512 Bytes

Detta betyder att om du skapar en VMFS datastore och väljer en blockize på ex. 1 MB så innebär detta att den inte kan lagra filer större än 256 GB – 512 Bytes. Om vi nu tittar på den VM som var aktuell i detta fall så hade den följande konfiguration:

VM-NAME

Disk 0:0 60 GB lagras på iSCSI-LUN-01 VMFS-blocksize 1 MB

Disk 0:1 300 GB lagras på iSCSI-LUN-05 VMFS-blocksize 4 MB

Disk 0:0 är i detta fall ”default virtual machine directory vilket innebär att en snapshot inte tillåts att skapas på denna då storleken på snapshoten i teorin skulle kunna överstiga den totala tillåtna storleken för denna datastore (vilket som sagt är 256 GB – 512 Bytes). Detta pga att Disk 0:1 är som ni ser är 300 GB dvs större än tillåtet.

Hur löser man då detta problem?

Alt 1.

Flytta den disk (med storage vmotion) som innehåller maskinens ”working directory” till en datastore med en större  blocksize .  Det är som standard den disk som innehåller ”.vmx” filen som är ”working directory”.

Alt 2.

Flytta endast konfigurationsfilen genom att köra en storage vmotion och endast välja ”.vmx” filen och på så vis byta ”working directory”.

För mer info se KB 1004040

Alt 3.

Ändra ”default virtual machine directory” till en datastore med större blocksize. Detta sker genom att manuellt redigera ”.vmx” filen för maskinen. Genom att göra detta kan man dirigera om alla snapshots till en annan datastore.

För instruktioner se KB 1002929

Mitt tips är att alltid använda sig utav den största blockstorleken (8 MB) konstant när man skapar sina VMFS volymer.

Duncan Epping – YellowBrick:  Block sizes and growing your VMFS


Automatisk inloggning i vCenter 2.5

I vCenter 4.0 och senare versioner kan man förenkla inloggningen med den tillhörande vSphere klienten genom att bocka i den lilla rutan längst ner och på så vis använda sig utav det windows konto man är inloggad med för att per automatik logga in på sin vCenter server. Denna möjlighet finns inte på den då kallade ”VMware Infrastructure Client” och vCenter version 2.5 eller tidigare . Det finns dock ett sätt att lösa detta på för att kunna vidarebefodra sina windows uppgifter och på så vis skapa en automatisk inloggning. Detta sker genom att man lägger till följande parametrar för genvägen till klienten.

-passthroughAuth -s vc.yourdomain.com

Byt ut ”vc.yourdomain.com” mot namnet eller ip adressen på din vCenter server. Nu har du möjligheten att automatiskt logga in på vCenter servern utan att ange autentiseringsuppgifter.

passthru

Partition alignment

Översätter man det engelska ordet ”Alignment” så får man följande förklaring: ”The act of adjusting or aligning the parts of a device in relation to each other”. De svenska alternativen är inriktning, justering eller linjering. Och det är precis vad detta inlägg kommer att handla om.

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).

diskpart1

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”

diskpart2

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.

disk-align-perf

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.

diskpart4

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”

diskpart3

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

Trimma prestandan i din vSphere miljö

Tänkte att jag så här dagen före dopparedagen skulle ge er läsare en liten julklapp. Detta i form av ett tips för att förbättra prestandan för dina virtuella maskiner i din vSphere miljö. Det har ju skett många förändringar i ESX4 vad gäller prestandan.

Tänkte här ta upp två stycken nya ”paravirtualiserade maskinvaror” som du kan nyttja och förhoppningsvis ge dig bättre pretsanda. Jag talar här om VMXNET3 ett nytt paravirtualiserat nätverkskort med stöd för bla 10GB ethernet och Jumbo Frames samt PVSCSI en ny paravirtualiserad SCSI-kontroller som skall ge ökad disk I/O med mindre belastning på CPU.

För att kunna använda denna nya ”virtuella hårdvara” som vSphere erbjuder och dess prestandaförbättringar krävs det att du uppgraderat dina virtuella maskiner till hårdvaruversion 7. Detta antar jag att alla som uppgraderat till vSphere redan har gjort. Om inte så följer här en snabb genomgång på hur detta sker:

  1. Börja med att uppgradera VMware Tools i ditt gästoperativsystem genom att högerklicka på den virtuella maskinen och välj ”Guest > Install/Upgrade VMware Tools”.
  2. När detta är klart kommer maskinen att boota om.
  3. Efter denna omstart stäng ner maskinen helt.
  4. Uppgradera sedan den virtuella maskinens hårdvara genom att högerklicka på den och välj ”Upgrade Virtual Hardware”.
  5. Starta nu upp din maskin och kontrollera att allt fungerar som det ska.
  6. Gör sedan en sista omstart.
  7. Klart!

Detta är uppgraderingsprocessen i komprimerad form och det viktiga här är att man installerar/uppgraderar VMware Tools innan man uppgraderar den virtuella hårdvaran till version 7.

Kommer här att kortfattat att beskriva hur man ”installerar” och nyttjar dessa nya virtuella maskinvaror och dess drivrutiner.

Installera VMXNET3 (Nytt paravirtualiserat nätverkskort)

För att kunna nyttja detta så måste man lägga till ett nytt nätverkskort till din virtuella maskin. Man kan alltså inte ändra typen för det befintliga nätverkskortet. Detta innebär att man måste notera IP-inställningarna för det gamla kortet och sedan konfigurera det nya med dessa. Tänk också på att MAC-adressen kommer att förändras. Bra att ha koll på om man har ex programvara som är knutet till denna.

  1. Börja med att notera IP-inställningarna för det nuvarande nätverkskortet.
  2. Lägg sedan till en ny ”Ethernet Adapter” till din VM genom att högerklicka på den och välj ”Edit Settings” > Hardware > Add > Ethernet Adapter”.
  3. Välj typen ”VMXNET3″ och se till att välja samma virtuella nätverk (portgrupp) som det tidigare nätverkskortet.
  4. Ta sedan bort det tidigare nätverkskortet genom att markera detta under ”Edit Settings” och klicka på remove.
  5. Konfigurera sedan det nya nätverkskortet med de IP-inställningarna som du noterat. (Windows kommer i detta läge att varna för att det finns ett tidigare nätverkskort med identisk konfiguration. Klicka bara OK på detta.)
  6. Öppna sedan en kommandotolk i din VM och kör ”ipconfig /flushdns” och ”ipconfig /registerdns”.
  7. Ditt nya paravirtualiserade VMXNET3 kort är nu konfigurerat och klart!

För att rensa och ta bort det gamla nätverkskortet och drivrutinen starta en kommandoprompt och skriv följande:

set devmgr_show_nonpresent_devices=1

start devmgmt.msc

Detta kommer att starta enhetshanteraren med möjligheten att visa dolda enheter. Välj sedan i menyn ”Visa > Visa dolda enheter”.  Radera sedan det gamla nätverkskortet under Nätverkskort.

För ytterligare info kring VMXNET och dess prestanda rekommenderas denna PDF från VMware:

http://www.vmware.com/pdf/vsp_4_vmxnet3_perf.pdf

Installera PVSCSI (Ny paravirtualiserat SCSI-kontroller)

Att lägga till en PVSCSI-kontroller är inte konstigare än att lägga till ytterligare en hårddisk till din VM. Att tänka på är dock att välja rätt SCSI-nod id. Detta skall vara 1:x där x = 1 tom 15 (tot 15 st SCSI enheter/adapter).

scsi-node

Detta gäller om du sedan tidigare endast har en SCSI-kontroller. Har du två st skall nod-id vara 2:x. Anledningen till att man gör på detta sättet är för att man skall få möjligheten att lägga till en ny SCSI-kontroller istället för att bara lägga till ytterligare en ny hårddisk på den första SCSI-kontrollern vilket skulle kunna bli node-id 0:1 (den första hårddisken har node-id 0:0). Man kan ha tot 4st SCSI-kontrollers per VM och 15st enheter/kontroller = tot 60 SCSI enheter. Så ex Hårddisk 5 på SCSI-kontroller 3 skulle ha ett node-id på 2:4. (Allt börjar på 0).

Vill man ändra typen (drivrutinen) på den befintliga SCSI-kontrollern som hanterar hårddisken man bootar från kan man inte göra detta endast genom att ändra detta. Maskinen kommer då inte klara av att boota då drivrutinen för SCSI-adaptern inte kommer att kännas igen av ex Windows vid uppstart vilket resulterar i en VM som ej bootar. För att lösa detta problem kan man använda sig av följande steg:

  1. Börja med att lägga till en ny hårddisk till din VM. ”Edit Settings” > Hardware > Add > Hard Disk”.
  2. Vart du väljer att lagra denna Hårddisk eller vilken storlek spelar ingen roll.
  3. Det viktiga är att välja rätt nod-id för den nya Hårddisken för att kunna addera ytterligare en SCSI-kontroller.
  4. Välj virtuell enhets nod-id. Detta skall vara mellan 1:x – 3:x. Se texten ovan för en förklaring kring detta.
  5. Ändra därefter typen på den nyligen adderade SCSI-kontrollern till VMware Paravirtual
  6. pvscsi-choose
  7. Sedan startar du upp din maskin för att Windows skall installera drivrutinen för den nya PVSCSI-kontrollern denna drivrutin hämtas från VMware Tools.
  8. Stäng sedan ner din maskin och ta bort den nya hårddisken genom att markera denna under ”Edit Settings > Hardware” och klicka på Remove.
  9. Välj sedan under ”Edit Settings > Hardware” att markera den primära SCSI-kontrollern och välj ”Change Type”. Välj typen VMware Paravirtual. Klicka sedan Ok och starta upp din VM. Klart!pvscsi

För att rensa och ta bort den gamla SCSI-kontrollern och drivrutinen starta en kommandoprompt och skriv följande:

set devmgr_show_nonpresent_devices=1

start devmgmt.msc

Detta kommer att starta enhetshanteraren med möjligheten att visa dolda enheter. Välj sedan i menyn ”Visa > Visa dolda enheter”.  Radera sedan den gamla SCSI-kontrollern.

För ytterligare info kring PVSCSI och dess prestanda rekommenderas denna PDF från VMware:

http://www.vmware.com/files/pdf/vsphere_performance_wp.pdf

Undantag och begränsningar

Både VMXNET3 och PVSCSI har sina begränsningar vad gäller viss funktionalitet i vSphere och stödet för specifika operativsystem. Exempelvis så fungerar varken VMXNET3 eller PVSCSI enheterna ihop med VMware FT vilket kan vara bra att veta för de som tänk nytta denna funktion för sin VM. PVSCI fungerar endast med Windows 2003, Windows 2008 och Redhat Enterprise Linux 5. Du kan endast använda PVSCI på din ”boot controller disk” alltså SCSI-adaptern för den hårddisken du bootar ditt operativsystem från om du kör ESX 4.0 Update 1 eller senare (fungerar med ESX 4.0 men är inte supporterat). Detta är bara några av de begränsningar som finns gällande dessa nya adapters/drivrutiner. Tror säkerligen att listan med begränsingar kommer att bli allt minder i takt med att VMware släpper nya versioner av vSphere, men jag vill ändå göra er uppmärksamma på att det finns och kan uppstå problem om man inte läser på innan dessa implementeras .

Passar härmed på att önska er läsare en riktigt

God Jul & Gott Nytt År!

P2V och Software RAID

Genomförde nyligen en P2V konvertering av en Windows server (2003 32bit). Servern hade 2st fysiska IDE-diskar som var speglade med Windows egna mjukvaruraid. Genomförde själva konverteringen med hjälp av VMware Converter.  Körde an så kallad ”Cold Clone” vilket innebär att man bootar den fysiska servern från en skiva där en anpassad version av Win-PE finns som startar VMware vCenter Converter. Föredrar att alltid använda denna metod vid P2V migreringar då risken för att dataförändringar under själva konverteringen försvinner helt.

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.