Windows 11 Hyper-V: az automatikus recovery forrásállapota és a korábbi guest-állapot visszajátszásának kizárása

Üdvözöljük a Microsoft Q&A oldalon

Megjegyzés: Ez az English (en-us) fórum. Tisztelettel javaslom, hogy kérdését angolul tegye közzé, mivel így a fórum más tagjai és a témakör szakértői könnyebben tudnak bekapcsolódni a kérdés megválaszolásába. Ha inkább magyarul szeretné közzétenni a kérdését, érdemes lehet a Kérdések - Microsoft Q&A is igénybe vennie, ahol nagyobb magyarul beszélő közönség tekintheti meg és válaszolhatja meg a kérdését. Köszönjük megértését.

Köszönöm, hogy időt szánt a forgatókönyv és a kialakítani kívánt biztonsági határ ilyen részletes ismertetésére.

A jelenleg közzétett Hyper-V dokumentáció alapján nem találok olyan támogatott Windows 11-beállítást, amely ilyen széles körű garanciát biztosítana. A dokumentáció különösen nem állítja, hogy minden VMMS- vagy munkafolyamat-helyreállítási útvonalnak a vendégrendszer új rendszerindításából kell kiindulnia, illetve hogy azok soha nem folytathatják a végrehajtást egy korábban megőrzött végrehajtási állapotból.

A fontos különbség az, hogy a Hyper-V-ben több különböző mód is létezik arra, ahogyan egy virtuális gép elindulhat, folytathatja a működését vagy helyreállítható, és ezeket nem szabad mind ugyanazon típusú helyreállításként kezelni.

Ha egy virtuális gép teljesen Off állapotban van, majd ezt követően elindítják, a vendégrendszer a konfigurált virtuális lemezeiről indul el. Hasonlóképpen, ha a vendégrendszert szabályosan leállítják, majd később elindítják, az a vendégrendszer új rendszerindítását jelenti, nem pedig a korábbi illékony memóriaállapot folytatását.

A pause és resume azonban másképp működik. A virtuális gép a meglévő illékony végrehajtási állapotát folytatja. Ez az aktuális VM-állapot folytatását jelenti, nem új rendszerindítást, és önmagában nem is egy korábbi ellenőrzőpontra történő visszaállást.

Az explicit Save művelet szintén különbözik a leállítástól. A virtuális gép mentése megőrzi az illékony állapotot, így a virtuális gép később ebből az állapotból folytathatja a működését. Ezért ha a kialakítás új végrehajtási útvonalat követel meg, egy megőrzött mentett állapotot külön kell kezelni egy Off állapotú virtuális géptől.

Az ellenőrzőpontok további különbséget jelentenek. Egy standard checkpoint tartalmazhatja a virtuális gép memóriaállapotát, ezért annak alkalmazása visszaállíthatja a vendégrendszert egy korábbi végrehajtási pontra. Egy production checkpoint nem őrzi meg ugyanilyen módon a futó vendégrendszer memóriáját. Ehelyett egy adatkonzisztens tárolási állapotot állít vissza, amely után a vendégrendszer ebből a visszaállított lemezállapotból indul el.

A gazdagép energiaállapot-változásait szintén külön kell figyelembe venni. A sleep és hibernation nem egyenértékű a teljes leállítással. Ezeket kifejezetten arra tervezték, hogy megőrizzék a rendszer állapotát, és így a végrehajtás később folytatódhasson. A Fast Startup hasonlóképpen hibernáláson alapuló mechanizmust használ, ezért nem szabad teljes hidegindítási határként kezelni, ha a követelmény a korábbi végrehajtási állapot elvetésétől függ.

A biztonsági mentés és a helyreállítás egy további állapot-visszaállítási útvonalat jelent. Egy Hyper-V biztonsági mentés megőrizheti a konfigurációs és futásidejű állapotinformációkat, így a virtuális gép később helyreállítható. Emiatt önmagában a normál ellenőrzőpontok letiltása nem tekinthető elegendőnek egy meglévő vagy már folyamatban lévő biztonsági mentési vagy helyreállítási művelet kizárásához.

Az AutomaticRecoveryAction esetében az örökölt CIM-dokumentáció a None (2), Restart (3) és Revert to snapshot (4) értékeket írja le. A "Revert to snapshot" egyértelműen egy korábbi pillanatképből történő helyreállítást jelent. A "Restart" dokumentációja külön kezeli ezt a visszaállítástól, azonban a rendelkezésre álló dokumentáció nem határoz meg kellően részletes CPU-/memória-forrásállapot-szerződést ahhoz, hogy megállapítható legyen: minden lehetséges munkafolyamat- vagy VMMS-helyreállításnak teljesítenie kell az Ön által megkövetelt erősebb, visszajátszást kizáró tulajdonságot.

A WMI-dokumentációban van egy érthető félreértési forrás is. Az AdditionalRecoveryInformation a None, Restart és Revert elemekhez kapcsolódó 0/1/2 megfogalmazást használja, míg az örökölt AutomaticRecoveryAction definíció 2/3/4 értékeket használ.

Nem javaslom ezeknek az értékeknek az átalakítását, eltolását vagy a közöttük lévő megfeleltetés találgatását. Az AdditionalRecoveryInformation további helyreállítási információ, nem pedig az AutomaticRecoveryAction kiválasztására szolgáló alternatív numerikus leképezés.

Ez különösen fontos, mivel az örökölt AutomaticRecoveryAction tulajdonság dokumentáltan read-only. Bár a ModifySystemSettings módosíthatja az Msvm_VirtualSystemSettingData támogatott írható tulajdonságait, ettől egy dokumentáltan csak olvasható tulajdonság még nem válik írhatóvá. Ezért nem támaszkodnék nem dokumentált WMI-értékre a biztonsági határ kikényszerítésének mechanizmusaként.

Ugyanez az óvatosság vonatkozik a RecoveryFile és .vmrs elemekre is. Létezésük jelezheti, hogy a Hyper-V számára rendelkezésre állnak futásidejű állapotinformációk, de önmagában a jelenlétük nem bizonyítja, hogy egy adott VM-helyreállítás ezt az állapotot betöltötte, vagy egy korábbi vendégrendszer-utasítást újra végrehajtott. A tényleges állapotátmenetet és a megfelelő Hyper-V eseményelőzményeket kell megvizsgálni.

Úgy tűnik, hogy a fő problémát az okozza, hogy több különböző mechanizmust az általános "helyreállítás" fogalom alatt kezelnek.

A Hyper-V esetében előfordulhat az aktuális VM-állapot folytatása, automatikus újraindítási viselkedés, explicit mentett állapot visszaállítása, ellenőrzőpont-visszaállítás, a gazdagép alvó vagy hibernált állapota, valamint biztonsági mentési/helyreállítási művelet. Ezek egyikének megakadályozása nem feltétlenül tiltja le az összes többit.

Például az ellenőrzőpontok letiltása segít megelőzni az ellenőrzőpontok létrehozását és az azokra történő későbbi visszaállást, de önmagában nem tiltja az explicit mentett állapotokat, a korábban megőrzött helyreállítási állapotokat, a gazdagép alvását vagy hibernálását, a VM biztonsági mentését/helyreállítását, az importálást vagy klónozást, illetve a már folyamatban lévő helyreállítási tevékenységet.

Hasonlóképpen, az AutomaticStartAction=None beállítása azt szabályozza, hogy mit tesz a Hyper-V a virtuális géppel a gazdagép indulásakor. Nem határozza meg, hogy mi történik belsőleg minden VM-munkafolyamat- vagy VMMS-hiba után.

Az AutomaticStopAction Shutdown vagy TurnOff értékre állítása a Save helyett megakadályozza, hogy a konfigurált gazdagép-leállítási művelet szándékosan mentse a virtuális gépet. Ezt a beállítást azonban nem szabad úgy értelmezni, hogy az alvás, a hibernálás, a VMMS-helyreállítás, a munkafolyamat-helyreállítás vagy a biztonsági mentés nem őrizhet meg állapotot.

Más szóval, az Ön által azonosított beállítások hasznos vezérlők, de a közzétett dokumentáció nem foglalja össze őket egy dokumentált "ez a virtuális gép soha nem folytathatja működését egy korábbi utasításállapotból" szerződésben.

Az Ön által leírt követelmény esetében azt javaslom, hogy a virtuális gépet fail-closed, kizárólag hidegindítású környezetként kezelje, ahelyett, hogy egy nem dokumentált helyreállítási beállítástól függne.

A kritikus időszak megkezdése előtt helyezze a virtuális gépet Off állapotba, és ellenőrizze, hogy nincs megőrzött mentett állapot. A virtuális gépet csak a tervezett felügyeleti/engedélyezési útvonalon keresztül indítsa el.

Az automatikus és az operátor által létrehozott ellenőrzőpontok maradjanak letiltva, és minden olyan korábban létező ellenőrzőpontot, amely képes a releváns állapot visszaállítására, támogatott Hyper-V-műveletekkel el kell távolítani, mielőtt az egyszer használatos engedély használhatóvá válik.

Az automatikus indítást állítsa None értékre, az automatikus leállítást pedig Shutdown vagy TurnOff értékre a Save helyett. Ezeket a beállításokat azonban kifejezetten a gazdagép indításának/leállításának vezérlőiként kezelje, ne általános helyreállítási garanciaként.

Ha egy állapotátmenet előtti végrehajtási pontról történő folytatás tiltott, akkor a gazdagép alvó állapotát, hibernálását, hibrid alvását és a Fast Startup használatát szintén ki kell zárni a kritikus munkafolyamatból.

A biztonsági mentési, helyreállítási, exportálási, importálási/klónozási és egyéb helyreállítási mechanizmusokat hasonlóképpen nyugalmi állapotba kell helyezni a kritikus időszak megkezdése előtt, beleértve minden olyan műveletet, amely már folyamatban volt.

A legfontosabb, hogy ha váratlan VMMS-kiesés, munkafolyamat-leállás, gazdagép-energiaállapot-változás, biztonsági mentési/helyreállítási állapot vagy egyéb olyan VM-helyreállítás következik be, amelynek forrásállapota nem sorolható be egyértelműen, akkor az eredményt ismeretlenként kell kezelni, és fail-closed módon kell eljárni. Ne próbálja automatikusan újra az egyszer használatos műveletet. Állítsa vissza a virtuális gépet az ismert Off alapállapotba, és követeljen meg új engedélyezési útvonalat.

Annak hiteles nyilvántartását, hogy az egyszer használatos művelet engedélyezve lett-e, befejeződött-e, meghiúsult-e, vagy ismeretlen eredményű állapotba került-e, a virtuális gép visszaállítási tartományán kívül kell tartani.

Ez a megközelítés nem állítja, hogy a Hyper-V visszajátszást kizáró garanciát biztosít. Ehelyett megakadályozza, hogy az alkalmazás olyan garanciától függjön, amelyet a jelenleg közzétett Hyper-V dokumentáció kifejezetten nem biztosít.

Továbbá azt javaslom, hogy ezt a viselkedést pontosan a Windows 11 Pro 25H2/build 26200 rendszeren ellenőrizze, mielőtt valódi engedélytokent vezetne be.

Használjon egy eldobható Generation 2 virtuális gépet, és rögzítse annak konfigurációs verzióját, aktuális állapotát, automatikus indítási/leállítási beállításait, az ellenőrzőpont-konfigurációt és -leltárt, valamint azt, hogy létezik-e bármilyen mentett állapot.

Megvizsgálhatja a telepített Root\Virtualization\V2 szolgáltatót és annak AutomaticRecoveryAction metaadatait, beleértve a ValueMap és Values minősítőket. Ezt azonban csak olvasási célú ellenőrzési lépésként kezelném, és nem vezetnék le írható helyreállítási beállítást az egymásnak ellentmondó 0/1/2, illetve 2/3/4 dokumentációból.

Ezután egymástól függetlenül tesztelje az egyes állapotátmeneteket, beleértve a hidegindítást, a pause/resume műveletet, az explicit save/resume műveletet, a VMMS újraindítását, az ellenőrzött munkafolyamat-hibát, a gazdagép sleep/hibernate állapotát és a biztonsági mentési tevékenységet. A vendégrendszer megfigyeléseit a Hyper-V-Worker és Hyper-V-VMMS eseménynaplókkal vesse össze, ahelyett, hogy a helyreállítási viselkedést kizárólag a .vmrs vagy egy másik állapotfájl jelenléte alapján határozná meg.

Továbbá szeretném tisztázni a Microsoft Q&A korlátozását ebben a konkrét esetben, hogy ne alakuljon ki az a benyomás, hogy a fórumbeli megerősítés hiánya azt jelenti, hogy a Hyper-V vagy biztonságosan megfelel ennek a követelménynek, vagy nem képes azt teljesíteni.

A Microsoft Q&A segíthet a közzétett dokumentáció, a támogatott beállítások és a dokumentált Hyper-V-viselkedés értelmezésében. A fórum azonban nem hozhat létre és nem tanúsíthat olyan termékgaranciát, amelyet a Microsoft közzétett támogatási szerződése nem tartalmaz.

Az Ön követelménye túlmutat a szokásos konfigurációs útmutatáson, mivel hiteles megerősítésre van szüksége arról, hogy a megadott Windows-build és hibafeltételek mellett egyetlen engedélyezett VMMS- vagy worker-helyreállítási útvonal sem tud visszaállítani egy korábbi vendégmemória-/utasításállapotot.

Nem gondolom, hogy helyénvaló lenne ezt a garanciát kizárólag a jelenleg rendelkezésre álló dokumentáció alapján megadni.

Ha ez a tulajdonság szükséges a biztonsági kialakításhoz, a megfelelő következő lépés egy Microsoft Windows/Hyper-V terméktámogatási eset megnyitása, amelyben megadja a Windows 11 pontos buildjét, a VM konfigurációs verzióját, a Generation 2 konfigurációt, az engedélyezett állapotátmeneteket és a hibaforgatókönyveket. A Microsoft terméktámogatása meg tudja állapítani, hogy a kért viselkedésre kiterjed-e a támogatott termékszerződés, vagy további mérnöki pontosítás szükséges.

Azt is javaslom, hogy küldjön dokumentációs visszajelzést az AutomaticRecoveryAction és az AdditionalRecoveryInformation 2/3/4, illetve 0/1/2 közötti eltéréséről, ahelyett, hogy megpróbálná kikövetkeztetni a kívánt beállítást.

Amíg a Microsoft terméktámogatása vagy a frissített termékdokumentáció nem biztosítja ezt a pontosítást, a legbiztonságosabb következtetés korlátozott, de fontos:

A jelenleg közzétett dokumentáció nem biztosítja a kért visszajátszást kizáró garanciát. Ennek a dokumentált garanciának a hiánya azonban önmagában nem értelmezhető annak bizonyítékaként, hogy visszajátszás fog történni, vagy hogy a Hyper-V alkalmatlan erre a kialakításra.

Remélem, ez segít tisztázni, hogy mi állapítható meg a jelenlegi dokumentáció alapján, és ugyanilyen fontos módon azt is, hogy hol van szükség a Microsoft terméktámogatásának állásfoglalására az Ön által igényelt erősebb garanciához.

Hivatkozások:

Msvm_VirtualSystemSettingData class - Win32 apps | Microsoft Learn

Virtuális gépek biztonsági mentése és visszaállítása - Win32 apps | Microsoft Learn

Set-VM (Hyper-V) | Microsoft Learn

Ellenőrzőpontok használata | Microsoft Learn

ModifySystemSettings method of the Msvm_VirtualSystemManagementService class - Win32 apps | Microsoft Learn

CIM_VirtualSystemSettingData class - Win32 apps | Microsoft Learn

Remove-VMSavedState (Hyper-V) | Microsoft Learn

Kapcsolatfelvétel a Microsoft ügyfélszolgálatával | Microsoft Support

Rendszerteljesítmény-állapotok - Win32 apps | Microsoft Learn

Restart-VM (Hyper-V) | Microsoft Learn

 Hyper-V biztonsági mentési módszerek | Microsoft Learn

The LocateSavedStateFiles function | Microsoft Learn

Ha hasznosnak találja, kérjük, kattintson az Accept Answer lehetőségre.

Köszönjük, hogy a Microsoft Q&A-t választotta.

Megjegyzés: Ez a válasz fordítóeszköz segítségével lett lefordítva. Kérjük, vegye figyelembe, hogy nyelvtani vagy szemantikai hibák előfordulhatnak. Köszönjük megértését.