Archive for the ‘Hyper-V’ Category

Automatisches Konvertieren von MBR-Bootfestplatten in GPT-Bootfestplatten in Windows, besonders auch für Hyper-V VMs

26 August 2018

Seit einigen Jahren gibt es immer mehr UEFI-Systeme. Was aber macht man, wenn man noch auf alter Master-Boot-Record Technologie, kurz MBR basierende Systeme hat? Windows 10 bringt seit der Version v1703 ein neues Programm Namens MBR2GPT.EXE mit. Mittels dieses Programms kann man eine Konvertierung vollautomatisiert durchführen.

Hier die gute und ausführliche Dokumentation von MS: https://docs.microsoft.com/en-us/windows/deployment/mbr-to-gpt. Im Normalfall geht man her, bootet ein Windows PE und führt dann MBR2GPT.EXE aus. Vor dem ersten Start von der konvertierten Festplatte muss man noch im UEFI-BIOS evtl. Einstellungen für den erfolgreichen Start mittels UEFI ändern.

Wie kann man dies nun auf virtuelle Maschinen vom Hyper-V anwenden? Muss man auch extra von WinPE booten oder gibt es eine Offline-Lösung? Tatsächlich gibt es diese, man kann also seine VHD oder VHDX-Images von MBR auf GPT-Partition umstellen, damit wird auch der Umstieg von Generation1-VMs auf Generation2-VMs möglich.

Die folgenden Schritte führt man also alle auf einem Host-System und nicht unter Windows PE durch. Zuerst geht man her und holt sich den Pfad der zu konvertierenden VHD-Datei:

$VMName = "win10Gen1"
$vm=get-vm $VMName
$vm.HardDrives[0].Path

Dann bindet man die VHD-Datei ein und ermittelt die zugehörige Disknummer:

Mount-VHD $vm.HardDrives[0].Path
$disk=get-disk|where location -eq $vm.HardDrives[0].Path
$disk.disknumber

Nun kann man prüfen, ob eine Konvertierung möglich ist:

.\MBR2GPT.EXE /allowFullOS /Validate /disk:$($disk.disknumber)

Dabei ist wichtig /allowFullOS anzugeben, da wir unter einem vollen Windows arbeiten. Wenn alles glatt geht, bekommt man z. B. diese Ausgabe:

MBR2GPT: Attempting to validate disk 1
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Nun kann man den eigentlichen Vorgang starten:

.\MBR2GPT.EXE /allowFullOS /Convert /disk:$($disk.disknumber)

und erhält nach Fertigstellung ungefähr diese Ausgabe:

MBR2GPT will now attempt to convert disk 1.
If conversion is successful the disk can only be booted in GPT mode.
These changes cannot be undone!

MBR2GPT: Attempting to convert disk 1
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Trying to shrink the system partition
MBR2GPT: Trying to shrink the OS partition
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Adding recovery boot entry
MBR2GPT: Fixing drive letter mapping
MBR2GPT: Conversion completed successfully
MBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

Nach diesem Vorgang muss nur noch die VHD-Datei getrennt werden:

Dismount-VHD $vm.HardDrives[0].Path

Nun muss man nur noch eine VM der Generation 2 erstellen und obige VHD-Datei dort einbinden und schon bootet man von GPT und kann nun sogar SecureBoot aktivieren.

Falls es Probleme mit MBR2GPT gibt, sei noch auf die beiden Dateien setuperr.log und setupact.log verwiesen, welche sich in C:\Windows befinden und nähere Infos für evtl. Probleme enthalten. Vor allem die setupact.log enthält viele Details zum Vorgang was MBR2GPT.EXE eigentlich so alles veranstaltet.

Schade ist allerdings, dass MBR2GPT.EXE nicht im Microsoft Hyper-V Server enthalten ist, leider auch nicht in der aktuellen Preview des kommenden Hyper-V Servers. Stellt sich aber die Frage, ob man die Version von Windows 10 benutzen kann? Kann man! MBR2GPT.EXE ist eine reine 64-Bit-Anwendung somit unter Microsoft Hyper-V Server einsetzbar. Es scheint genauso wie auf Windows 10 zu funktionieren, sobald man /allowFullOS angibt läuft es.

Jetzt fehlt eigentlich nur noch ein Script, welches eine VM Generation 1 hernimmt und in eine VM Generation 2 automatisch konvertiert.

Advertisements

Hyper-V SecondaryStatusDescription meldet “The protocol version of the component…” bei VSS

11 April 2018

Auf einem Hyper-V 2016 Server wurde bei Windows VMs bei der Ausgabe von Get-VMIntegrationService beim VSS die Meldung “The protocol version of the component…” ausgegeben. Was bedeutet die Meldung genau und was ist die Lösung?

Zuerst dachte ich an ein Problem mit Updates der Hyper-V Integration Services. Da aber die betreffende VM eine Windows 10 Maschine war und diese automatisch die Updates für die Integrationskomponenten bekommt, war die Meldung etwas komisch. https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/Manage-Hyper-V-integration-services#integration-service-maintenance.

Mehr Informationen kann man sich anschauen mittels

(Get-VMIntegrationService VMName).SecondaryOperationalStatus

hier wird dann ein “ProtocolMismatch” gemeldet, den genaueren Text bekommt man mittels

(Get-VMIntegrationService VMName).SecondaryStatusDescription

Dieser lautet:

The protocol version of the component installed in the virtual machine does not match the version expected by the hosting system

Aber was ist jetzt das Problem? Schaut man sich mittels Get-VM die Daten der VM an, dann fällt die Version auf:

Name         State   CPUUsage(%) MemoryAssigned(M) Uptime           Status             Version
—-         —–   ———– —————– ——           ——             ——-
VMName Running 1           2546              01:28:49.6250000 Operating normally 5.0

Dazu muss man wissen, dass bei Server 2016 Version 8 bei neuen VMs verwendet wird. In diesem Fall stammte die VM aber von einem Server 2012 R2 und da gab es maximal Version 5.0.

Nachdem dann mittels

Update-VMVersion VMName

die Version auf die aktuelle 8.0 aktualisiert wurde, verschwand auch die dubiose Protokollfehlermeldung. ABER Vorsicht! Man bekommt zwar mehr Möglichkeiten durch Version 8.0 allerdings verliert man auch das einsehbare XML-Format der Konfigurationsdateien. Auch kann man VMs nicht mehr mit älteren Hyper-V Servern verwenden!

Schnelle Übersicht der Switchzuordnungen von VMs bei einem Hyper-V Server

28 März 2018

Beim Testen von verschiedenen Netzen oder Betriebssystemen auf einem Hyper-V Server verliert man meistens nach einiger Zeit den Überblick über die Switch-Zuordnungen. Leider hat die Management-Konsole von Haus aus nur einfache Einstellungsmöglichkeiten aber keine Übersicht.

Aber man kann sich ja mittels Powershell behelfen. Mit dieser kleinen Zeile bekommt man aufgelistet welcher Switch mit welcher VM verbunden ist:

get-vm| Select @{N="VMName";E={$_.Name}},@{N="Switch";E={$_.NetworkAdapters.Switchname}},@{N="IPAddresses";E={$_.Networkadapters.IPAddresses}} | sort Switch | select Switch, VMName, IPAddresses

Wird die Darstellung auch zu unübersichtlich, dann bietet es sich an, dass man Out-GridView verwendet, damit man schnell suchen und neu sortieren kann:

get-vm| Select @{N="VMName";E={$_.Name}},@{N="Switch";E={$_.NetworkAdapters.Switchname}},@{N="IPAddresses";E={$_.Networkadapters.IPAddresses}} | sort Switch | select Switch, VMName, IPAddresses| Out-GridView

Taucht in der Spalte Switch kein Name auf, dann ist der betreffenden VM auch kein Switch zugeordnet. Gibt es mehrere Namen, dann hat die VM mehrere Netzwerkkarten eingebaut und kann mit verschiedenen Netzen kommunizieren oder hat evtl. Teaming aktiviert.

Außerdem könnte noch bei der Übersicht der Switchtype interessant sein:

get-vm| Select @{N="VMName";E={$_.Name}},@{N="Switch";E={$_.NetworkAdapters.Switchname}},@{N="IPAddresses";E={$_.Networkadapters.IPAddresses}},@{N="SwitchType";E={(Get-VMSwitch $_.NetworkAdapters.SwitchName).SwitchType}} | sort Switch | select Switch, VMName, IPAddresses, SwitchType

Hyper-V Ereignisanzeige-Einträge erklärt

24 Januar 2018

Klappt bei einem Hyper-V etwas nicht, dann helfen auch mal die Ereigniseintragungen von Windows zur Problemlösung. Allerdings gibt es nicht einen, sondern je nach Problem verschiedene Eventlogs. Hier eine aktuelle Übersicht mit kurzen Beschreibungen für 2016: https://blogs.technet.microsoft.com/virtualization/2018/01/23/looking-at-the-hyper-v-event-log-january-2018-edition/

Hier noch die Verwendung in Powershell:

Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-VMMS
Get-WinEvent -ProviderName Microsoft-Windows-VHDMP

Ausgabe alle verfügbaren Hyper-V LogProvider (ok, VHDMP fehlt):

Get-WinEvent -ListProvider *hyper-v*

Noch kurz zur Verwendung der Cmdlets: Wenn man sich vertippt, erhält man diese Meldung:

PS> Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-GibtesNicht
Get-WinEvent : Auf dem Computer "localhost" wurde kein Ereignisanbieter gefunden, der "Microsoft-Windows-Hyper-V-GibtesNicht" entspricht.
In Zeile:1 Zeichen:1
+ Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-GibtesNicht
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft-Windows-Hyper-V-GibtesNicht:String) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingProvidersFound,Microsoft.PowerShell.Commands.GetWin
EventCommand

Wohingegen, wenn man einen gültigen Ereignisanbieter verwendet, aber keine Ereigniseinträge vorhanden sind, diese Meldung erscheint:

PS > Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-Config
Get-WinEvent : Es wurden keine Ereignisse gefunden, die den angegebenen Auswahlkriterien entsprechen.
In Zeile:1 Zeichen:1
+ Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-Config
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingEventsFound,Microsoft.PowerShell.Commands.GetWinEvent
Command

Bildschirminhalt einer virtuellen Maschine im Hyper-V Server abrufen

6 Dezember 2017

Wenn man auf einem Microsoft Hyper-V Server (https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-server-2016) unterwegs ist, also der frei verfügbaren Version, dann hat man manchmal das Problem, dass man wissen möchte, warum eine virtuelle Maschine noch nicht ansprechbar ist. Meist hat es mit einem Hänger oder mit blöden Updates zu tun. Falls man nun aber direkt auf der Konsole des Servers ist, dann gibt es keine direkten grafischen Mittel die passenden Infos abzurufen.

Aus diesem Grund hab ich ein Script gebastelt, damit man in Zukunft die passenden Funktionen direkt verfügbar hat. Hier zunächst die Ausgangslage, wie man das Bild einer virtuellen Maschine speichert (https://blogs.msdn.microsoft.com/virtual_pc_guy/2016/05/27/capturing-a-hyper-v-vm-screen-to-a-file/) daraus resultierte dieses abgewandelte Skript:

Daraus ergeben sich die Funktionen:

# speichern in eine Datei
Save-VMScreen –VMName SampleVMName –Filename ".\test.bmp"

# direkte Ausgabe am Bildschirm
Show-VMScreen  –VMName SampleVMName

Man kann noch einen Parameter –Index angeben, dieser ist als Vorgabe 0 und spricht einen spezifischen Videohead an. Wie dieser genau definiert ist, ließ sich leider nicht herausfinden. Aber kurz gesagt, kann man damit höher aufgelöste Bilder erhalten.

Man kann sogar das aktuelle Bild in die Windows-Zwischenablage legen, damit man es für Dokuzwecke woanders wieder einfügen kann:

[System.Windows.Forms.Clipboard]::SetImage((Get-VMScreenBMP "SampleVMName"))

Konvertieren von virtuellen Festplattenimages in VHD oder VHDX zur Verwendung in Hyper-V oder Azure

25 August 2017

Man bekommt immer wieder Images von anderen virtuellen Maschinen die man in Hyper-V einbinden möchte. Ich hatte hier schon mal auf ein Utility von Microsoft verlinkt: https://newyear2006.wordpress.com/2012/09/04/konvertieren-von-virtuellen-vmware-maschinen-in-virtuelle-hyper-v-maschinen/. Leider klappt der Link nicht mehr. Auf der Suche nach einer Alternative bin ich auf ein Image-Utility von Qemu gestoßen, welches im Prinzip alle gängigen Formate konvertieren kann. Ein weiterer Vorteil ist, dass es als Open Source vorliegt.

Hier die Binary: https://cloudbase.it/qemu-img-windows/ und hier der Source in github: https://github.com/cloudbase/qemu/. Hier gibt es die ausführliche Hilfe: https://qemu.weilnetz.de/doc/qemu-doc.html#qemu_005fimg_005finvocation.

Es werden alle gängigen Formate unterstützt:

Image-Format (schreibbar) qemu-img Parameter
QCOW2 (KVM, Xen) qcow2
QEMU qcow
QED (KVM) qed
raw raw
VDI (VirtualBox) vdi
VHD (Hyper-V) vpc
VMDK (VMware) vmdk
Linux dm-crypt/cryptsetup luks

Neben obigen Formaten, welche gelesen und geschrieben werden können, gibt es noch ein paar, welche nur gelesen werden können:

Image-Format (nur lesbar) qemu-img Parameter
Bochs x86 PC emulator bochs
Linux Compressed Loop image cloop
Apple disk image dmg
Parallels disk image format parallels

Zu jedem Format gibt es noch spezielle Parameter, eine Beschreibung dazu findet man hier: https://qemu.weilnetz.de/doc/qemu-doc.html#disk_005fimages_005fformats.

Zur Anwendung kann man z. B.

qemu-img.exe convert source.img -O vhdx -o subformat=dynamic dest.vhdx

aufrufen.

Man kann auch den Parameter info verwenden um Informationen über ein Image zu erfahren.

C:\>qemu-img info test.img
image: test.img
file format: vhdx
virtual size: 127G (136365211648 bytes)
disk size: 4.0M
cluster_size: 33554432

Aber Vorsicht, man kann sich nicht immer voll auf die Infos verlassen, denn in Fällen wo unsinnige Daten verwendet werden, werden trotzdem Daten ausgegeben:

C:>echo "Nix da" > test.txt
C:>qemu-img info test.txt
image: test.txt
file format: raw
virtual size: 512 (512 bytes)
disk size: 11

Dabei muss der Hinweis auf das Dateiformat RAW nicht immer heißen, dass es kein gültiges Dateisystem ist! Es bedeutet vielmehr, dass qemu-img das Format nicht zuordnen kann.

Obwohl das Tool ziemlich mächtig ist, fehlt noch die Möglichkeit .GHO-Dateien von Symantec Ghost konvertieren zu können. Dazu gibt es über einen Umweg die Möglichkeit mittels Ghost in VMDK-Dateien und dann mittels qemu-img in VHDX zu konvertieren:

ghost64 -clone,mode=restore,src=source.gho,dst=image.vmdk -batch –sure
qemu-img.exe convert image.vmdk -O vhdx -o subformat=dynamic dest.vhdx

Damit wird Source.GHO in Dest.VHDX konvertiert.

Hier sind noch weitere Parameter für die Konvertierung bei Ghost beschrieben: https://www.symantec.com/connect/articles/converting-image-file-format-gho-vmdk-and-vmdk-gho.

Dank qemu-img hat man nun ein mächtiges Tool für Festplattenimages an der Hand.

Hardware direkt einer virtuellen Maschine im Hyper-V mittels Discrete Device Assignment zuordnen

3 Juni 2016

Microsoft experimentiert viel mit dem Hyper-V und baut ihn in alle Richtungen aus. So gab es ganz zu Beginn von Windows 10 Powershell Cmdlets, welche es erlaubten physische Hardware direkt einer virtuellen Maschine zuzuordnen https://charbelnemnom.com/2015/02/whats-new-in-powershell-for-hyper-v-in-windows-server-technical-preview-hyperv-powershell-vnext/. Dazu gab es die Cmdlets:

Get-Command *assigna*

Name                            Version Source
—-                            ——- ——
Add-VMAssignableDevice          2.0.0.0 Hyper-V
Add-VMHostAssignableDevice      2.0.0.0 Hyper-V
Dismount-VMHostAssignableDevice 2.0.0.0 Hyper-V
Get-VMAssignableDevice          2.0.0.0 Hyper-V
Get-VMHostAssignableDevice      2.0.0.0 Hyper-V
Mount-VMHostAssignableDevice    2.0.0.0 Hyper-V
Remove-VMAssignableDevice       2.0.0.0 Hyper-V
Remove-VMHostAssignableDevice   2.0.0.0 Hyper-V

Allerdings verschwanden diese Cmdlets wieder zum Release von Windows 10, weshalb sie bei diesem Vergleich nicht auftauchten: https://newyear2006.wordpress.com/2015/07/30/umgang-mit-verschiedenen-versionen-von-powershellmodulen-und-ermittlung-von-unterschieden/.

Per Zufall stolperte ich aber über diesen Blogeintrag https://techstronghold.com/blogs/virtualization/pass-through-wired-or-wireless-wi-fi-nic-to-vm-using-hyper-v-discrete-device-assignment-dda-in-windows-server-2016, der komische Dinge vollführte. Tatsächlich hat Microsoft obige Cmdlets mit Release von v1511 bei Windows 10 wieder eingeführt! Wobei die Dokumentation, stand heute, also ein halbes Jahr nach Erscheinen von v1511, absolut erbärmlich ist. Z. B. besteht die Dokumentation von Add-VMAssignableDevice nur aus einem Template. Keine Erklärung nix.

Nun ist das Thema an sich auch recht komplex, aber man könnte ja zumindest ein paar Links für weitergehende Informationen hinterlegen. So muss man sich alles selber ergooglen.

Im Prinzip geht es um Discrete Device Assignment, kurz DDA, auch bekannt als PCI Passthrough. Dies erlaubt einer VM den direkten Zugriff auf Hardware.

Hier findet man einen Hintergrundartikel dazu: https://blogs.technet.microsoft.com/virtualization/2015/11/19/discrete-device-assignment-description-and-background/. Obwohl die Cmdlets unter Windows 10 verfügbar sind, scheint nur unter Windows Server 2016 die Unterstützung aktiviert zu sein! Dies wird in diesem Artikel geschrieben: https://blogs.technet.microsoft.com/virtualization/2015/11/20/discrete-device-assignment-machines-and-devices/.

Selbst wenn man mit dem Server 2016 unterwegs ist, muss die Hardware DDA unterstützen, ein Script welches die Hardware daraufhin überprüft, ist hier zu finden: https://github.com/Microsoft/Virtualization-Documentation/blob/master/hyperv-tools/DiscreteDeviceAssignment/SurveyDDA.ps1.

WLAN bzw. WIFI mit Hyper-V

3 Mai 2016

Endlich wird es einfacher möglich auf Windows 10 seinen WLAN-Adapter für VMs unter Hyper-V zu verwenden. Hier die passende Beschreibung: https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/user_guide/setup_nat_network?f=255&MSPPError=-2147217396

Leider geht es aber erst ab Build 14295 oder später.

Im Prinzip braucht man drei Powershell-Aufrufe:

New-VMSwitch
https://technet.microsoft.com/de-de/library/hh848455.aspx
New-NetIPAddress
https://technet.microsoft.com/en-us/library/hh826150.aspx
New-NetNat
https://technet.microsoft.com/de-de/library/dn283361(v=wps.630).aspx

Umgang mit verschiedenen Versionen von Powershellmodulen und Ermittlung von Unterschieden

30 Juli 2015

Microsoft hat mit Veröffentlichung von Windows 10 auch neue Cmdlets für Powershell eingeführt. Bei Windows 10 Pro und vergleichbaren Versionen, wo der Client Hyper-V enthalten ist, gibt es viele neue Cmdlets für die Verwaltung von virtuellen Maschinen. Interessant dabei ist, dass es eine neue Version des Hyper-V-Moduls gibt. Bis Windows 8.1 und Server 2012 R2 kam die Version 1.1 zum Einsatz und mit Windows 10 gibt es das Hyper-V-Modul in Version 2.0.0.0.

Aus Kompatibilitätsgründen macht es Sinn ein Modul mit einer spezifischen Version zu laden. Vor allem, wenn man z. B. vergleichen möchte, was sich in der neuen Version des Moduls verändert hat.

Welche Version aktuell geladen ist, bekommt man mit Get-Module heraus:

PS> get-module hyper-v

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     1.1        hyper-v                             {Add-VMDvdDrive,…

Mittels Remove-Module kann man das Modul entladen und mit Hilfe von Get-Module –Listavailable erhält man alle verfügbaren Versionen:

PS> Remove-Module hyper-v
PS> Get-Module -ListAvailable Hyper-V

    Verzeichnis: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     2.0.0.0    Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMGroupMember, Add-VMHardDiskDrive…}
Binary     1.1        Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMHardDiskDrive, Add-VMMigrationNetwork…}

Mittels Import-Module kann man nun ein Modul laden:

PS> Import-Module Hyper-V
PS> Get-Module Hyper-V

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     2.0.0.0    Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMGroupMember, Add-VMHardDiskDrive…}

Man bekommt automatisch die neueste Version. Mit dem Parameter –RequiredVersion kann man nun eine spezifische Version laden:

Import-Module Hyper-V -RequiredVersion 1.1

Nun kann man mittels dieser Möglichkeit beide Versionen laden, die Cmdlets einer Variablen zuweisen und diese Vergleichen lassen:

PS> Import-Module Hyper-V -RequiredVersion 1.1
PS> $cV1 = Get-Command -Module Hyper-V
PS> Remove-Module Hyper-V
PS> Import-Module Hyper-V -RequiredVersion 2.0.0.0
PS> $cV2 = Get-Command -Module Hyper-V
PS> compare $cv1 $cv2

InputObject                              SideIndicator
———–                              ————-
Add-VMGroupMember                        =>
Add-VMNetworkAdapterRoutingDomainMapping =>
Add-VMSwitchTeamMember                   =>
Add-VMTPM                                =>
Disable-VMConsoleSupport                 =>
Enable-VMConsoleSupport                  =>
Get-VHDSet                               =>
Get-VHDSnapshot                          =>
Get-VMGroup                              =>
Get-VMHostCluster                        =>
Get-VMNetworkAdapterIsolation            =>
Get-VMSwitchTeam                         =>
Get-VMTPM                                =>
Get-VMVideo                              =>
New-VMGroup                              =>
Optimize-VHDSet                          =>
Remove-VHDSnapshot                       =>
Remove-VMGroup                           =>
Remove-VMGroupMember                     =>
Remove-VMSwitchTeamMember                =>
Rename-VMGroup                           =>
Set-VMHostCluster                        =>
Set-VMNetworkAdapterIsolation            =>
Set-VMNetworkAdapterRoutingDomainMapping =>
Set-VMSwitchTeam                         =>
Set-VMTPM                                =>
Set-VMVideo                              =>
Start-VMTrace                            =>
Stop-VMTrace                             =>
Update-VMVersion                         =>
Add-VmNetworkAdapterRoutingDomainMapping <=
Get-VmNetworkAdapterIsolation            <=
Set-VmNetworkAdapterIsolation            <=
Set-VmNetworkAdapterRoutingDomainMapping <=

Dabei fällt auf, dass keine Cmdlets entfernt wurden, auch wenn es auf den ersten Blick so aussieht. Es wurde lediglich die Schreibweise bei den letzten vier Cmdlets von …-Vm… in …-VM… geändert.

Halten wir also fest, dies sind die neuen Cmdlets in Hyper-V 2.0.0.0:

Add-VMGroupMember
Add-VMNetworkAdapterRoutingDomainMapping
Add-VMSwitchTeamMember
Add-VMTPM
Disable-VMConsoleSupport
Enable-VMConsoleSupport
Get-VHDSet
Get-VHDSnapshot
Get-VMGroup
Get-VMHostCluster
Get-VMNetworkAdapterIsolation
Get-VMSwitchTeam
Get-VMTPM
Get-VMVideo
New-VMGroup
Optimize-VHDSet
Remove-VHDSnapshot
Remove-VMGroup
Remove-VMGroupMember
Remove-VMSwitchTeamMember
Rename-VMGroup
Set-VMHostCluster
Set-VMNetworkAdapterIsolation
Set-VMNetworkAdapterRoutingDomainMapping
Set-VMSwitchTeam
Set-VMTPM
Set-VMVideo
Start-VMTrace
Stop-VMTrace
Update-VMVersion

Hyper-V schnelles Backup einer VM und anschließende Probleme

23 April 2015

Wenn man meint bei einem Hyper-V mal schnell eine Sicherung einer VHD zu machen (ohne einen Snapshot zu erstellen) und die VHD wegkopiert, dem kann es passieren, dass beim Zurückkopieren der VHD und anschließendem Start der VM folgender Fehler auftaucht:

[Window Title]
Verbindung mit virtuellen Computern

[Main Instruction]
Anwendungsfehler beim Versuch, den Status von "XSlave" zu ändern.

[Content]
Fehler beim Starten von "XSlave".

Microsoft Emulated IDE Controller (Instanz-ID {83F8638B-8DCA-4152-9EDA-2CA8B33039B4}): Fehler "Allgemeiner "Zugriff verweigert"-Fehler" beim Einschalten.

Das IDE/ATAPI-Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler"

Das -Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler"

[Expanded Information]
Fehler beim Starten von "XSlave" (ID des virtuellen Computers 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B).

"XSlave" Microsoft Emulated IDE Controller (Instanz-ID {83F8638B-8DCA-4152-9EDA-2CA8B33039B4}): Fehler "Allgemeiner "Zugriff verweigert"-Fehler" (0x80070005) beim Einschalten (ID des virtuellen Computers: 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B).

"XSlave": Das IDE/ATAPI-Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler" (0x80070005). (ID des virtuellen Computers: 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B)

"XSlave": Das -Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler" (0x80070005). (ID des virtuellen Computers: 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B)

[V] Details einblenden  [Schließen]

In diesem Fall hilft der Datei die passenden Rechte mittels ICACLS zu geben, maßgeblich:

icacls x1slave.vhd /grant "NT Virtueller Computer\9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B:(R,W)"

Näheres findet man hier: https://support.microsoft.com/en-us/kb/2249906/en.