04/09/2011
At administrere en virtuel infrastruktur med VMware er ofte en smidig proces, men enhver administrator kender til frustrationen, når en tilsyneladende simpel opgave som at udvide en virtuel harddisk pludselig fejler. Fejlmeddelelser som "invalid configuration for device 0" eller "invalid operation on device 3" kan stoppe arbejdet og skabe usikkerhed. Disse problemer kan opstå i både vCenter og direkte på en ESXi-host, og de skyldes ofte underliggende konfigurationsproblemer, låste filer eller endda den måde, disken oprindeligt blev oprettet på. Heldigvis findes der flere metoder til at diagnosticere og løse disse udfordringer, lige fra simple tricks til mere avancerede kommandoer og konverteringer.

Denne artikel vil guide dig igennem de mest almindelige årsager til, at du ikke kan udvide en virtuel disk, og give dig en række konkrete løsningsforslag. Vi dækker alt fra grundlæggende fejlsøgningstrin, brug af PowerCLI til at omgå grafiske brugerfladefejl, til den afgørende forskel på MBR- og GPT-partitionstabeller, som ofte er den oversete synder.
Forstå de almindelige årsager til diskudvidelsesfejl
Før vi dykker ned i løsningerne, er det vigtigt at forstå, hvorfor disse fejl opstår. Problemet er sjældent relateret til en enkeltstående fejl, men snarere en kombination af faktorer i dit virtuelle miljø. Her er nogle af de hyppigste årsager:
- Aktive Snapshots: Den mest almindelige årsag. Når en virtuel maskine har en eller flere snapshots, låses den virtuelle disks (VMDK) konfigurationsfil. Det er ikke muligt at ændre størrelsen på en disk, før alle snapshots er slettet (committed). Selvom du tror, du ikke har nogen, kan der ligge skjulte eller konsolideringskrævende snapshots tilbage.
- Kommunikationsproblemer: Nogle gange er fejlen ikke på selve VM'en, men i kommunikationen mellem vCenter Server og den ESXi-host, hvor VM'en kører. En genstart af management-agenterne kan ofte løse dette.
- Forkert CD/DVD-drev konfiguration: Hvis VM'ens virtuelle CD/DVD-drev peger på en ISO-fil, der ikke længere eksisterer eller er utilgængelig, kan det forhindre andre konfigurationsændringer, herunder diskstørrelse.
- Diskpartitionstype (MBR vs. GPT): En ofte overset årsag er, at disken bruger den ældre MBR-partitionstabel (Master Boot Record). MBR har en begrænsning på 2 TB pr. partition. Hvis du forsøger at udvide en disk ud over denne grænse, vil operationen fejle. Konvertering til GPT (GUID Partition Table) er nødvendig.
- Metadata-inkonsistens: Især ved diske, der er blevet gendannet fra backup (f.eks. via Datto), klonet med værktøjer som `vmkfstools`, eller flyttet mellem forskellige datastores, kan der opstå små uoverensstemmelser i diskens metadata. Dette kan forvirre vCenter, selvom disken fungerer fint inde i gæsteoperativsystemet.
Metode 1: Grundlæggende fejlsøgningstrin
Start altid med de simpleste løsninger, da de ofte kan løse problemet uden behov for mere drastiske indgreb. Gennemgå disse trin systematisk.
1. Kontrollér og konsolidér snapshots
Selvom du ikke kan se nogen snapshots i Snapshot Manager, kan der stadig være behov for konsolidering. Højreklik på VM'en, vælg 'Snapshots' og derefter 'Consolidate'. Dette rydder op i eventuelle resterende snapshot-filer og kan frigøre låsen på disken.
2. Sluk for den virtuelle maskine
Nogle operationer kræver, at den virtuelle maskine er slukket. Selvom mange moderne VMware-versioner understøtter 'hot-add' af diskplads, kan visse låse eller konfigurationer forhindre det. Prøv at lukke VM'en helt ned (ikke genstarte) og forsøg derefter at udvide disken.
3. Genstart Management Agents
Hvis du har mistanke om et kommunikationsproblem mellem vCenter og ESXi-hosten, kan en genstart af agenterne hjælpe. Dette kan gøres via hostens DCUI (Direct Console User Interface) eller via en SSH-forbindelse med følgende kommandoer:
/etc/init.d/hostd restart /etc/init.d/vpxa restartBemærk, at hosten kortvarigt vil miste forbindelsen til vCenter, men de kørende virtuelle maskiner påvirkes ikke.
Metode 2: Brug PowerCLI når den grafiske brugerflade fejler
Nogle gange er fejlen isoleret til vSphere Client (både HTML5 og den ældre Flash-version). I disse tilfælde kan man ofte omgå problemet ved at bruge PowerCLI, som er VMwares kommandolinjeværktøj baseret på PowerShell. PowerCLI interagerer direkte med vSphere API'en og er mindre følsom over for de små GUI-bugs, der kan opstå.
Et konkret eksempel, hvor en bruger ikke kunne udvide den sidste disk på en VM, men havde udvidet andre diske uden problemer få minutter før, blev løst med en enkelt PowerCLI-kommando. Kommandoen Set-HardDisk er yderst effektiv til denne opgave.

Sådan gør du:
- Åbn en PowerCLI-session og forbind til din vCenter Server eller ESXi-host med `Connect-VIServer`.
- Identificér den korrekte disk og VM.
- Kør kommandoen. Erstat 'MyVMName', 'Hard disk 1' og '100' med dine egne værdier.
Get-HardDisk -VM MyVMName | Where-Object {$_.Name -eq "Hard disk 1"} | Set-HardDisk -CapacityGB 100 -Confirm:$falseParameteren `-Confirm:$false` forhindrer, at du skal bekræfte handlingen manuelt. Denne metode er utrolig kraftfuld og har reddet mange administratorer fra at skulle slukke for kritiske virtuelle maskiner.
Metode 3: Konvertering fra MBR til GPT
Hvis du oplever problemer med diske, der nærmer sig 2 TB, eller hvis du ser mærkelige størrelsesangivelser (f.eks. i TB med mange decimaler i stedet for GB), er synderen næsten helt sikkert, at disken bruger MBR-partitionstypen. MBR er en ældre standard med betydelige begrænsninger i dagens dataintensive verden.
Sammenligning: MBR vs. GPT
Tabellen nedenfor illustrerer de vigtigste forskelle:
| Egenskab | MBR (Master Boot Record) | GPT (GUID Partition Table) |
|---|---|---|
| Maksimal diskstørrelse | 2 TB | 9.4 ZB (Zettabytes) - praktisk talt ubegrænset |
| Maksimalt antal primære partitioner | 4 | 128 (i Windows) |
| Datasikkerhed | Partitionsdata gemmes kun ét sted. Sårbar over for korruption. | Gemmer flere kopier af partitionsdata og bruger CRC32-tjeksummer til at opdage korruption. |
| Kompatibilitet | Ældre systemer (før UEFI) | Moderne systemer med UEFI-firmware |
For at løse problemet skal MBR-disken konverteres til GPT. Dette kan gøres inde fra gæsteoperativsystemet (f.eks. Windows eller Linux). I Windows kan dette gøres med værktøjer som `Disk Management` eller kommandolinjeværktøjet `mbr2gpt.exe`, men det kræver ofte, at disken er tom. For diske med data er det sikreste at bruge tredjepartsværktøjer, som kan udføre konverteringen uden datatab. Det er dog altafgørende at tage en fuld backup af den virtuelle maskine eller som minimum disken, før du starter en sådan proces.
Ofte Stillede Spørgsmål (OSS)
Er det sikkert at konvertere en disk fra MBR til GPT?
Ja, med moderne værktøjer er processen generelt sikker og pålidelig. Men som med enhver fundamental diskoperation er der altid en lille risiko. Derfor er en solid backup ikke bare en anbefaling – det er et krav. Tag et snapshot (og slet det efterfølgende) eller en fuld backup af VM'en, før du begynder.
Min disk er gendannet fra en backup og opfører sig mærkeligt. Hvad kan jeg gøre?
Diske, der er blevet gendannet, især fra tredjeparts backup-løsninger, kan nogle gange have små fejl i deres deskriptorfiler (.vmdk). En effektiv løsning kan være at 'klone' disken. Enten ved at bruge vCenters 'Clone' funktion til at oprette en ny VM baseret på den gamle, eller ved at bruge `vmkfstools -i` via kommandolinjen til at oprette en ny, 'ren' kopi af disken. Dette kan ofte rette op på metadata-fejl.
Hvorfor virker PowerCLI, når vSphere Client fejler?
vSphere Client er en applikation med sit eget lag af kode, validering og session-håndtering. Nogle gange kan fejl i denne applikation (f.eks. i JavaScript-koden) eller cache-problemer forhindre en operation i at blive sendt korrekt til vCenter. PowerCLI taler mere direkte med vSphere API'en og er derfor ikke påvirket af disse frontend-problemer. Det er et uundværligt værktøj til avanceret administration og fejlsøgning.
Hvis du vil læse andre artikler, der ligner Løs VMware-diskfejl ved resizing, kan du besøge kategorien Teknologi.
