Hyper-V I/O-prestanda för lagring

2025-08-16
Gäller för: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows 10

Den här artikeln utforskar olika alternativ och överväganden för att justera prestanda för indata/utdata för lagring (I/O) på en virtuell dator (VM). I/O-sökvägen för lagring sträcker sig över fyra på varandra följande steg:

Stack för gästlagring
Lager för värdvirtualisering
Lagringsstack för värd
Fysisk disk

I följande avsnitt beskrivs de optimeringar som är möjliga för varje steg.

Virtuella styrenheter

Hyper-V erbjuder tre typer av virtuella styrenheter:

Integrerad drivelektronik (IDE)
Gränssnitt för små datorsystem (SCSI)
Virtuella Fibre Channel-värdbusskort (HBA)

IDE

Vi rekommenderar att du endast använder IDE-diskar för OS-diskar. OS-diskar har prestandabegränsningar baserat på den maximala I/O-storleken för sina enheter.

IDE-styrenheter är emulerade styrenheter som exponerar IDE-diskar för den virtuella datorn. Den här typen av kontrollant är det enda alternativet för virtuella gästdatorer som kör tidigare versioner av Windows utan Hyper-V VM-integreringstjänster. IDE-filterdrivrutinen som Integration Services tillhandahåller kan utföra disk-I/O bättre än den emulerade IDE-styrenheten.

SCSI (SAS-styrenhet)

Virtuella SCSI-styrenheter exponerar SCSI-diskar för den virtuella datorn. Varje SCSI-styrenhet har stöd för upp till 64 enheter. SCSI-sökvägen emuleras inte, vilket gör den till den föredragna styrenheten för alla andra diskar än OS-disken. Windows Server 2012 R2 och senare stöder SCSI-styrenheter, men endast i scenarier där du rapporterar kontrollanten som en SAS (Serial Attached SCSI) för stöd för en delad virtuell hårddisk (VHDX).

För bästa prestanda rekommenderar vi att du ansluter flera diskar till en enda virtuell SCSI-styrenhet. Du bör bara skapa fler kontrollanter om du inte har några andra alternativ för att skala hur många diskar som är anslutna till den virtuella datorn.

Virtuella Fibre Channel-värdbussavtal

Konfigurera virtuella Fibre Channel-värdbussavtal så att virtuella datorer kan få direkt åtkomst till Fibre Channel och FCoE-nummer (Fibre Channel over Ethernet) logiska enheter (LUN). Virtuella Fibre Channel-diskar kringgår NTFS-filsystemet i rotpartitionen, vilket minskar användningen av CPU (Central Processing Unit) för lagring. Virtuella Fibre Channel-diskar är bra för stora dataenheter och enheter som delas mellan flera virtuella datorer i gästklusterscenarier.

Om du vill använda virtuella Fibre Channel-diskar måste du installera en eller flera Fibre Channel-värdbussbrickor på värddatorn. Varje värd-HBA måste använda HBA-drivrutiner som stöder Windows Server 2016 Virtual Fibre Channel eller NPIV-funktioner (N_Port ID Virtualization). SAN-infrastrukturen (Storage Area Network) bör också ha stöd för NPIV, och du bör konfigurera HBA-portarna för Fibre Channel i en Fibre Channel-topologi som stöder NPIV.

För att maximera dataflödet på värdar med fler än en HBA rekommenderar vi att du konfigurerar många virtuella HBA:er i den Hyper-V virtuella datorn. Du kan konfigurera upp till fyra HBA:er för varje virtuell dator. Hyper-V balanserar automatiskt virtuella HBA:er så att de är värdar för HBA:er som har åtkomst till samma virtuella SAN.

Virtuella diskar

Virtuella diskar exponeras för de virtuella datorerna av virtuella styrenheter och kan vara virtuella hårddiskar eller direktdiskar på värden.

Virtuella diskar finns i VHD- eller VHDX-format. Varje format har stöd för tre typer av virtuella hårddiskfiler.

Om du uppgraderar distributionen till Windows Server 2016 eller senare rekommenderar vi att du konverterar alla VHD-filer till VHDX-format. Mer information finns i VHDX-format.

VHD-format

Senare versioner av Hyper-V innehåller förbättringar av VHD-formatet som möjliggör bättre justering. Hyper-V i Windows Server 2012 och senare stöder både VHDX- och VHD-format, till skillnad från tidigare versioner som endast stöder VHD-format. Det innebär att senare versioner av Hyper-V presterar bättre på stora sektordiskar.

Alla virtuella hårddiskar som du skapar i Windows Server 2012 eller senare har den optimala justeringen på 4 KB. Det här justerade formatet är helt kompatibelt med tidigare versioner av Windows Server. Justeringsegenskapen stöder dock inte nya allokeringar från parsers som inte är justeringsmedvetna om 4 kB, till exempel en parser från en tidigare version av Windows Server eller en parser som inte kommer från Microsoft.

Konvertera disk till VHD-format

När du migrerar en virtuell hårddisk från en tidigare version av Hyper-V eller Windows Server till en senare version konverteras inte disken automatiskt till VHD-format.

Du kan konvertera en befintlig virtuell disk till en virtuell hårddisk genom att öppna ett PowerShell-fönster och köra följande kommando:

Convert-VHD –Path <SourceDiskFilePath> –DestinationPath <ConvertedDiskFilePath>

Om du till exempel planerade att konvertera en källdisk med namnet test.vhd på enhet E till en omdöpt konverterad disk med namnet test-converted.vhd i samma mapp skulle du köra det här kommandot:

Convert-VHD –Path E:\vms\testvhd\test.vhd –DestinationPath E:\vms\testvhd\test-converted.vhd

Note

När du konverterar en virtuell hårddisk använder PowerShell data från den virtuella källhårddisken baserat på alternativet Kopiera från källdisk . Mer information finns i Konvertera-VHD.

Kontrollera diskjusteringen

När du har konverterat en disk kan du kontrollera dess justeringsvariabel för att se till att den använder den optimala 4 KB-justeringen Get-VHD genom att köra kommandot i PowerShell. Se till att köra kommandot för källdisken och den konverterade disken och jämför sedan värdena för att se till att den konverterade disken är 4 KB justeringsmedveten.

Så här visar du justeringen av dina diskar:

Öppna ett PowerShell-fönster.
Kör kommandot Get-VHD för att visa justeringsinställningen för källdisken.
```
Get-VHD –Path <SourceVHDFilePath>
```

Lägg märke till värdet för Alignment egenskapen i utdata. I det här exemplet är 0värdet , vilket innebär att disken inte är justeringsmedveten på 4 kB.

Path                    : <SourceVHDFilePath>
VhdFormat               : VHD
VhdType                 : Dynamic
FileSize                : 69245440
Size                    : 10737418240
MinimumSize             : 10735321088
LogicalSectorSize       : 512
PhysicalSectorSize      : 512
BlockSize               : 2097152
ParentPath              :
FragmentationPercentage : 10
Alignment               : 0
Attached                : False
DiskNumber              :
IsDeleted               : False
Number                  :

Kör kommandot igen, men den här gången använder du filsökvägen för den konverterade disken Get-VHD .
```
Get-VHD –Path <ConvertedDiskFilePath>
```

I utdata kontrollerar du värdet för egenskapen Alignment . Värdet ska vara 1, vilket innebär att disken har konverterats till det nyare VHD-formatet och är 4 KB justeringsmedveten.

Path                    : <ConvertedDiskFilePath>
VhdFormat               : VHD
VhdType                 : Dynamic
FileSize                : 69369856
Size                    : 10737418240
MinimumSize             : 10735321088
LogicalSectorSize       : 512
PhysicalSectorSize      : 512
BlockSize               : 2097152
ParentPath              :
FragmentationPercentage : 0
Alignment               : 1
Attached                : False
DiskNumber              :
IsDeleted               : False
Number                  :

VHDX-format

VHDX är ett uppdaterat hårddiskformat som introducerades i Windows Server 2012. Det här formatet kan skapa motståndskraftiga, högpresterande virtuella diskar med upp till 64 terabyte kapacitet.

Om du uppgraderar till Windows Server 2016 eller senare rekommenderar vi att du konverterar alla VHD-filer till VHDX-format. Behåll bara filer i VHD-format om du behöver flytta den virtuella datorn till en tidigare Hyper-V version som inte stöder VHDX-format.

Här är några fördelar med VHDX-formatet:

Stöd för lagringskapacitet på virtuell hårddisk på upp till 64 terabyte
Skydd mot skadade data vid strömavbrott genom att logga uppdateringar av VHDX-metadatastrukturerna
Lagrar anpassade metadata för en fil baserat på vad användaren som konfigurerar den vill spela in, till exempel OS-versionen eller tillämpade korrigeringar

VHDX-formatet innehåller också flera prestandafunktioner:

Förbättrad justering av det virtuella hårddiskformatet, vilket förbättrar prestanda på stora sektordiskar
Större blockstorlekar för dynamiska och differentiella diskar, vilket gör att diskarna kan justeras efter arbetsbelastningskrav
En virtuell disk med logisk sektor på 4 KB som stöder ökad prestanda när den används av program och arbetsbelastningar som är utformade för sektorer på 4 KB
Effektivitet när det gäller att representera data för att skapa mindre filstorlekar och göra det möjligt för underliggande fysiska lagringsenheter att frigöra oanvänt utrymme

Note

Trimning kräver genomströmnings- eller SCSI-diskar och trimningskompatibel maskinvara.

Virtuella filer

Det finns tre typer av VHD-filer:

Fasta filer är till för att förbättra återhämtning och prestanda, och du bör använda dem när lagringen på värdvärdet inte övervakas aktivt. Kontrollera att det finns tillräckligt med diskutrymme när du expanderar VHD-filen vid körning. Du kan använda dem på vilket diskformat som helst.
Dynamiska filer är till för återhämtningsgarantier och för att allokera diskutrymme när distributionen behöver det. Du kan bara använda dem på VHDX.
Differentieringsfiler håller kedjorna för VM-ögonblicksbilder korta för att upprätthålla bra disk-I/O-prestanda. Du kan använda dem på vilket diskformat som helst.

Fast filtyp

När du skapar en fast VHD-fil allokerar systemet utrymme för den. Fasta filer är mindre benägna att fragmenteras, vilket minskar I/O-dataflödet när en enda I/O delas upp i flera. Den har också den lägsta CPU-overheaden av de tre filalternativen eftersom läs- och skrivåtgärder inte behöver leta upp mappningen av blocket.

Vi rekommenderar att du använder den fasta filtypen när du behöver optimal återhämtning och prestanda.

Dynamisk filtyp

När du skapar en dynamisk VHD-fil allokerar systemet utrymme för den på begäran. Block i filen börjar som allokerade block och inget utrymme i filen backar upp de oallokerade blocken. När ett block tar emot sin första skrivning måste virtualiseringsstacken allokera utrymme för blocket i VHD-filen och sedan uppdatera metadata. Den här allokeringen ökar antalet disk-I/O som krävs för skrivningen, vilket ökar CPU-användningen. Läsningar och skrivningar till befintliga block medför diskåtkomst och CPU-kostnader när du letar upp blockens mappning i metadata.

Om du använder en VHDX-fil rekommenderar vi att du använder den dynamiska filtypen när du inte aktivt övervakar lagringen på värdvolymen. Kontrollera att du har tillräckligt med diskutrymme när du expanderar VHD-filen vid körning.

Differentierande filtyp

Differentieringsfiler är ögonblicksbilder av en virtuell dator som lagrar skrivningar till diskarna. Om du skriver till ett block utan befintliga skrivningar allokerar systemet utrymme i VHD-filen precis som en dynamiskt expanderande virtuell hårddisk. Systemtjänsterna läser åtgärder från VHD-filen om blocket redan innehåller skrivningar. Annars tjänstblock från den överordnade VHD-filen. I båda fallen läser systemet metadata för att fastställa blockmappningen. Läsningar och skrivningar till den här virtuella hårddisken kan förbruka mer CPU och resultera i fler I/O än en fast VHD-fil.

När det bara finns några få ögonblicksbilder kan lagrings-I/O potentiellt använda mer CPU än normalt, men det påverkar inte märkbart prestanda förutom i mycket I/O-intensiva serverarbetsbelastningar. Att skapa och använda en stor kedja av ögonblicksbilder av virtuella datorer orsakar prestandaproblem. I differentieringsfiler måste systemet söka efter de begärda blocken i många olika differentierande virtuella hårddiskar bara för att läsa från den virtuella hårddisken. Om du använder differentieringsfiler rekommenderar vi att du håller ögonblicksbildskedjorna korta för att upprätthålla bra disk-I/O-prestanda.

Storleksöverväganden

När du planerar för diskoptimering bör du överväga både blockstorlek och sektorstorlek. I det här avsnittet beskrivs rekommendationer för storleksändring av block och sektorer.

Blockstorlek

Eftersom blockstorleken kan påverka prestanda avsevärt rekommenderar vi att du matchar blockstorleken med allokeringsmönstren för arbetsbelastningarna med hjälp av disken. Om ett program allokerar block i segment på 16 MB bör du helst använda en VHD-blockstorlek på 16 MB. Blockstorlekar som är större än 2 MB är endast möjliga på virtuella hårddiskar som använder VHDX-filformatet. När blockstorleken är större än allokeringsmönstret för en slumpmässig I/O-arbetsbelastning ökar mängden utrymme som den virtuella hårddisken använder på värden.

Sektorstorlek

Programvaruorganisationer är ofta beroende av disksektorer på 512 byte, men branschstandarden håller på att flyttas till disksektorer på 4 KB. För att minska kompatibilitetsproblem som kan uppstå på grund av ändringar i sektorstorlek introducerar hårddisktillverkare en övergångsstorlek som kallas 512-emuleringsenheter (512e).

Emuleringsenheter erbjuder några av fördelarna med inbyggda diskenheter på 4 KB, till exempel förbättrad formateffektivitet och ett förbättrat schema för felkorrigeringskoder (ECC). Emuleringsenheter ger färre kompatibilitetsproblem när du exponerar en sektorstorlek på 4 KB i diskgränssnittet.

Om du vill utnyttja 4 KB-sektorer fullt ut rekommenderar vi att du använder VHDX-formatet i stället för disksektorer på 512 byte. Om du vill minska kompatibilitetsproblem mellan diskstorlekar implementerar du 512e-enheter för övergångsstorlek.

Stöd för övergångsstorlek med 512e-diskar

En 512e-disk kan endast utföra en skrivoperation när det gäller en fysisk sektor. Den här typen av disk kan inte direkt skriva en 512 byte-sektor som systemet utfärdar den till. Disken har en intern process som gör skrivoperationer möjliga, vilket omfattar RMW-operationer (Read-Modify-Write) i följande ordning:

Först läser disken den fysiska sektorn på 4 KB till den interna cachen. Cachen innehåller den logiska sektorn på 512 byte som refereras till i skrivåtgärden.
Därefter ändrar disken data i bufferten på 4 KB så att den innehåller den uppdaterade sektorn på 512 byte.
Slutligen skriver disken tillbaka den uppdaterade bufferten på 4 KB till sin fysiska sektor på disken.

Den totala effekten som RMW-processen har på prestanda beror på arbetsbelastningen. RMW-processen kan orsaka prestandaförsämring på virtuella hårddiskar av följande skäl:

Dynamiska och differentiella VHD:er har en sektorbitmapp på 512 byte framför sin datanyttolast. Positionerare för sidfot, sidhuvud och överordnad justeras mot en sektor på 512 byte. Det är vanligt att den virtuella hårddiskdrivrutinen kör skrivåtgärder på 512 byte för att uppdatera dessa strukturer, vilket gör att disken kör RMW-processen.
Program kör ofta läs- och skrivåtgärder i multiplar av 4 KB-storlekar, eftersom 4 KB är standardklusterstorleken för NTFS. Dynamiska och differentierande virtuella hårddiskar har en sektorbitmapp på 512 byte framför datanyttolastblocket. Den här bitmappen gör att blocken på 4 kB inte justeras mot den fysiska gränsen på 4 kB. Följande diagram visar ett markerat VHD 4-KB-block som inte är justerat med den fysiska 4-KB-gränsen.

Varje skrivåtgärd på 4 KB av den aktuella tolken för att uppdatera nyttolastdata resulterar i två läsningar för två block på disken. Systemet uppdaterar sedan blocken och skriver tillbaka dem till de två diskblocken. Hyper-V i Windows Server 2016 minskar vissa prestandaeffekter på 512e-diskar på VHD-stacken. Hyper-V förbereder strukturerna för justering till 4 KB-gränser i VHD-format. Lösningen undviker RMW-effekten på åtkomsten till data i den virtuella hårddiskfilen och uppdateringar av metadatastrukturerna för den virtuella hårddisken.

Som tidigare nämnts justeras inte virtuella hårddiskar som kopierats från tidigare versioner av Windows Server automatiskt till 4 kB. Du kan konvertera disken manuellt så att den justeras optimalt med hjälp av alternativet Kopiera från källdisk med kommandot Convert-VHD .

Som standard exponeras virtuella hårddiskar med en fysisk sektorstorlek på 512 byte. Den här metoden säkerställer att beroende program av fysisk sektorstorlek inte påverkas när du migrerar programmet och de virtuella hårddiskarna från en tidigare version av Windows Server.

Som standard skapar systemet VHDX-diskar med en fysisk sektorstorlek på 4 KB för att optimera prestandaprofilen på vanliga diskar och större sektordiskar.

För att minska kompatibilitetsproblem mellan diskstorlekar rekommenderar vi att du implementerar 512e-enheter för övergångsstorlek. Om du vill utnyttja 4 KB-sektorer fullt ut använder du VHDX-format.

Interna diskar på 4 KB

Hyper-V i Windows Server 2012 R2 och senare har stöd för inbyggda diskar på 4 KB. Du kan också lagra VHD-diskdata på en intern disk på 4 KB genom att implementera en RMW-algoritm för programvara i det virtuella lagringsstacklagret. Algoritmen konverterar åtkomst- och uppdateringsbegäranden på 512 byte till motsvarande åtkomst och uppdateringar på 4 KB.

Eftersom VHD-filer bara kan exponeras som diskar med logisk sektorstorlek på 512 byte är det troligt att det finns program som utfärdar I/O-begäranden på 512 byte. I sådana fall uppfyller RMW-algoritmen i lagringsstacklagret begärandena och orsakar prestandaförsämring. Samma resultat uppstår för VHDX-diskar med en logisk sektorstorlek på 512 byte.

Du kan konfigurera VHDX-filer så att de exponeras som en disk med logisk sektorstorlek på 4 KB. Den här implementeringen är en optimal konfiguration för prestanda för diskar som finns på en inbyggd fysisk enhet på 4 KB. Kontrollera dock att storleken på 4 KB logisk sektor stöder både gästen och programmet som använder den virtuella disken. VHDX-formatet fungerar korrekt på en enhet med logisk sektorstorlek på 4 KB.

Vi rekommenderar att du undviker att använda inbyggda diskar på 4 KB med VHD- och VHDX-filer, eftersom det kan orsaka prestandaförsämring. När ditt scenario kräver inbyggda diskar på 4 KB bör du använda VHDX-formatet på en enhet med logisk sektorstorlek på 4 KB.

Direktdiskar

Vi rekommenderar att du undviker att använda direktdiskar på grund av de begränsningar som de medför i scenarier för VM-migrering.

Att mappa en virtuell hårddisk på en virtuell dator direkt till en fysisk disk eller ett lun-nummer (logisk enhet) i stället för en VHD-fil kallas för direktdisk genomströmningsdiskar så att du kan kringgå NTFS-filsystemet i rotpartitionen, vilket minskar CPU-användningen av lagrings-I /O. Användning av direktdiskar innebär dock också en risk för att fysiska diskar eller LUN blir svårare att migrera mellan datorer än VHD-filer.

Avancerade lagringsfunktioner

I det här avsnittet beskrivs några fler prestandaoptimeringar som du bör överväga för avancerade lagringsfunktioner.

Tjänstkvalitet för lagring (QoS)

I Windows Server 2012 R2 och senare innehåller Hyper-V möjligheten att ange vissa QoS-parametrar (Quality-of-Service) för lagring på virtuella datorer. Vi rekommenderar att du implementerar QoS för lagring för att få åtkomst till extra lagringsparametrar, ange högsta och lägsta IOPS-tröskelvärden för virtuella hårddiskar och övervaka diskprestanda. Du kan implementera dessa parametrar för att få följande fördelar:

Konfigurera isolering av lagringsprestanda i en miljö med flera klientorganisationer
Ange högsta och lägsta indata-/utdataåtgärder per sekund (IOPS) för virtuella hårddiskar
- Administratörer kan begränsa lagrings-I/O för att förhindra att en klientorganisation förbrukar för stora lagringsresurser som kan påverka andra klienter. Ange det lägsta IOPS-värdet och ta emot meddelanden när systemet inte uppfyller tröskelvärdet för optimala prestanda. Vi anger de högsta eller lägsta IOPS-värdena när det gäller normaliserad IOPS där vi var 8 kB data som en I/O.
Ta emot meddelanden när I/O-prestanda för lagring understiger definierade tröskelvärden för att effektivt köra VM-arbetsbelastningar
Få åtkomst till lagringsparametrar för infrastruktur för VM-mått och gör det möjligt för administratörer att övervaka prestanda och återbetalningsrelaterade parametrar

Tänk dock också på att QoS för lagring har följande begränsningar:

Endast tillgängligt för virtuella diskar
Differentieringsdisken kan inte ha en överordnad virtuell disk på en annan volym
QoS för en replikplats konfigureras separat från den primära platsen
QoS för lagring stöder inte delad VHDX

Mer information finns i Tjänstkvalitet för lagring för Hyper-V.

NUMA I/O-registerinställningar för stora virtuella datorer

Windows Server 2012 och senare stöder projicering av en virtuell, icke-enhetlig NUMA-topologi (Memory Access) till Hyper-V virtuella datorer. NUMA-stöd förbättrar prestandan för arbetsbelastningar som körs på virtuella datorer som konfigurerats med stora mängder minne eller stora virtuella datorer. För att aktivera det här stödet kräver stora VM-konfigurationer skalbarhet när det gäller I/O-dataflöde. Ett exempel på en stor virtuell dator är Microsoft SQL Server som körs med 64 virtuella processorer.

Följande Windows Server-förbättringar uppfyller I/O-skalbarhetskraven för stora virtuella datorer:

Skapa fler kommunikationskanaler mellan gästenheter och värdlagringsstacken.
En effektivare mekanism för I/O-komplettering som involverar avbrottsdistribution mellan de virtuella processorerna för att undvika dyra avbrott mellan processorer.

Registernycklar

Vi rekommenderar att du använder inställningarna för Windows Server NUMA-registernyckeln för att förbättra prestanda för arbetsbelastningar som körs på stora virtuella datorer.

Vi har lagt till och uppdaterat några registerposter för att stödja förbättringarna i föregående avsnitt och göra att du kan justera antalet kanaler. Du hittar posterna på HKLM\System\CurrentControlSet\Enum\VMBUS\<device id>\<instance id>\StorChannel.

Den <device id>\<instance id>\ del av sökvägen motsvarar de relevanta värdena i konfigurationen. Dessa registerposter justerar de virtuella processorer som hanterar I/O-slutföranden till de virtuella processorer som programmet har tilldelat som I/O-processorer. Systemet konfigurerar registerinställningar per adapter på enhetens maskinvarunyckel.

Här är två viktiga inställningar att tänka på:

ChannelCount (DWORD) är det totala antalet kommunikationskanaler som distributionen kan använda. Det maximala värdet är 16. Kanalantalet är som standard ett värde som är lika med antalet virtuella processorer dividerat med 16.
ChannelMask (QWORD) är processortillhörigheten för kanalerna. Om du inte anger den här nyckelinställningen eller anger värdet till 0 används som standard den befintliga algoritmen för kanaldistribution för normala lagrings- eller nätverkskanaler. Standardåtgärden säkerställer att dina lagringskanaler inte står i konflikt med dina nätverkskanaler.

Integrering av avlastad dataöverföring

Vi rekommenderar att du använder ODX-åtgärder (Offloaded Data Transfer) för att säkerställa att den virtuella datorns arbetsbelastning kan använda ODX-aktiverad lagring på samma sätt som i en fysisk miljö.

Viktiga underhållsuppgifter för virtuella hårddiskar, till exempel sammanslagning, flyttning och komprimering, omfattar kopiering av stora mängder data. Den aktuella metoden för att kopiera data kräver att systemet läser och skriver data till olika platser, vilket är tidskrävande och använder processor- och minnesresurser som kunde ha gått till att underhålla virtuella datorer.

SAN-leverantörer (Storage Area Network) kan tillhandahålla en maskinvarufunktion som kallas ODX. Den här funktionen ger nästan omedelbara kopieringsåtgärder för stora mängder data. ODX gör det möjligt för systemet, inte diskarna, att ange hur specifika datamängder ska flyttas från en plats till en annan.

Hyper-V i Windows Server 2012 och senare stöder ODX-åtgärder för att skicka kopierade data från gästoperativsystemet till värdmaskinvaran. Arbetsbelastningen kan använda ODX-aktiverad lagring precis som i en icke-virtualiserad miljö. Den Hyper-V lagringsstacken kan också utfärda ODX-åtgärder under underhållsåtgärder för virtuella hårddiskar, till exempel sammanslagning av diskar och lagring av migreringsmetaåtgärder under enorma datamigreringar.

Integrering av avisering om avbildning

Vi rekommenderar att du använder unmap-meddelanden för att göra dina VHDX-filer mer effektiva och låta den underliggande fysiska lagringsenheten återta oanvänt utrymme.

VHD-filer finns på en lagringsvolym där de delar tillgängligt utrymme med andra filer. Eftersom VHD-filerna ofta är stora kan de ta upp mycket utrymme. Större efterfrågan på lagringsutrymme påverkar IT-hårdvarubudgetar, vilket innebär att du bör optimera användningen av fysiskt utrymme där det är möjligt.

I versioner av Windows Server tidigare än Windows Server 2012 hade Windows-lagringsstacken i gästoperativsystemet och den Hyper-V värden begränsningar som hindrade dem från att optimera lagringsutrymmet. När program tog bort innehåll på en virtuell hårddisk förblev lagringsutrymmet övergivet. Systemet meddelar inte den virtuella hårddisken eller den fysiska lagringsenheten om den borttagna informationen, vilket förhindrade att den Hyper-V lagringsstacken optimerade utrymmet för de VHD-baserade virtuella diskfilerna. Därför kunde den underliggande lagringsenheten inte återta det nu oanvända utrymmet som de raderade data brukade uppta.

Från och med Windows Server 2012 stöder Hyper-V avbildningsmeddelanden. Med den här funktionen kan VHDX-filer rapportera borttagna data till lagringsstacken, vilket maximerar effektiviteten genom att hålla filstorlekarna trimmade och låta stacken frigöra oanvänt lagringsutrymme för andra användningsområden.

Endast Hyper-V-specifika SCSI-, IDE- och Virtual Fibre Channel-styrenheter tillåter unmap att kommandot från gästoperativsystemet når den virtuella värdlagringsstacken. På virtuella hårddiskar stöder unmap endast virtuella diskar som formaterats som VHDX kommandon från gästoperativsystemet.

Feedback

Var den här sidan till hjälp?