Vertrouwde start implementeren voor Azure Arc-VM's op Azure Stack HCI, versie 23H2
Van toepassing op: Azure Stack HCI, versie 23H2
In dit artikel wordt beschreven hoe u trusted launch implementeert voor virtuele Azure Arc-machines (VM's) in Azure Stack HCI, versie 23H2.
Vereisten
Zorg ervoor dat u toegang hebt tot een Azure Stack HCI- versie 23H2-cluster dat is geïmplementeerd en geregistreerd bij Azure. Zie Implementeren met de Azure Portal voor meer informatie.
Een vertrouwde start-ARC-VM maken
U kunt een vertrouwde start-VM maken met behulp van Azure Portal of met behulp van Azure Command-Line Interface (CLI). Gebruik de onderstaande tabbladen om een methode te selecteren.
Als u een vertrouwde start van een Arc-VM wilt maken in Azure Stack HCI, volgt u de stappen in Virtuele Arc-machines maken in Azure Stack HCI met behulp van Azure Portal, met de volgende wijzigingen:
Selecteer tijdens het maken van de virtuele machine Vertrouwde virtuele machines starten als beveiligingstype.
Selecteer een installatiekopieën van een VM-gastbesturingssystemen in de lijst met ondersteunde installatiekopieën:
Zodra een VM is gemaakt, gaat u naar de pagina VM-eigenschappen en controleert u of het weergegeven beveiligingstype Vertrouwd starten is.
Voorbeeld
In dit voorbeeld ziet u een vertrouwde arc-VM die wordt gestart Windows 11 gast waarop BitLocker-versleuteling is ingeschakeld. Hier volgen de stappen voor het uitvoeren van het scenario:
Maak een vertrouwde start arc-VM met een ondersteund Windows 11 gastbesturingssysteem.
BitLocker-versleuteling inschakelen voor het volume van het besturingssysteem op de Win 11-gast.
Meld u aan bij de Windows 11 gast en schakel BitLocker-versleuteling in (voor het besturingssysteemvolume): typ BitLocker beheren in het zoekvak op de taakbalk en selecteer dit in de lijst met resultaten. Selecteer BitLocker inschakelen en volg de instructies voor het versleutelen van het besturingssysteemvolume (C:). BitLocker gebruikt vTPM als sleutelbeveiliging voor het besturingssysteemvolume.
Migreer de VM naar een ander knooppunt in het cluster. Voer de volgende PowerShell-opdracht uit:
Move-ClusterVirtualMachineRole -Name $vmName -Node <destination node name> -MigrationType Shutdown
Controleer of het eigenaarsknooppunt van de VM het opgegeven doelknooppunt is:
Get-ClusterGroup $vmName
Nadat de VM-migratie is voltooid, controleert u of de VM beschikbaar is en Of BitLocker is ingeschakeld.
Controleer of u zich kunt aanmelden bij de Windows 11 gast op de VIRTUELE machine en of BitLocker-versleuteling voor het besturingssysteemvolume ingeschakeld blijft. Als u dit kunt doen, bevestigt dit dat de vTPM-status is behouden tijdens de VM-migratie.
Als de vTPM-status niet behouden blijft tijdens de migratie van de VM, zou het opstarten van de VM hebben geresulteerd in BitLocker-herstel tijdens het opstarten van de gast. Dat wil dat u om het BitLocker-herstelwachtwoord wordt gevraagd wanneer u zich probeerde aan te melden bij de Windows 11 gast. Dit komt doordat de opstartmetingen (opgeslagen in de vTPM) van de gemigreerde VM op het doelknooppunt afwijken van die van de oorspronkelijke VM.
Dwing de VM om een failover uit te voeren naar een ander knooppunt in het cluster.
Bevestig het eigenaarsknooppunt van de VM met behulp van deze opdracht:
Get-ClusterGroup $vmName
Gebruik Failoverclusterbeheer om de clusterservice op het eigenaarsknooppunt als volgt te stoppen: Selecteer het eigenaarsknooppunt zoals weergegeven in Failoverclusterbeheer. Selecteer in het rechterdeelvenster Actiesde optie Meer acties en selecteer vervolgens Clusterservice stoppen.
Als u de clusterservice op het eigenaarsknooppunt stopt, wordt de VM automatisch gemigreerd naar een ander beschikbaar knooppunt in het cluster. Start de clusterservice daarna opnieuw op.
Nadat de failover is voltooid, controleert u of de VM beschikbaar is en Of BitLocker is ingeschakeld na de failover.
Controleer of het eigenaarsknooppunt van de VM het opgegeven doelknooppunt is:
Get-ClusterGroup $vmName
Volgende stappen
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor