Archive for the ‘Virtualisierung’ Category

Qnap virtuelle Rechner per Terminal mittels virtsh verwalten

22 Juni 2019

Bei QNAP NAS-Modellen mit einem Intel Prozessor kann man virtuelle Maschinen direkt auf dem NAS mittels KVM einrichten. Die Oberfläche der Virtualization Station ist schön aufgeräumt und einfach gehalten. Aber aus genau diesem Grund findet man nicht alle Punkte, die man eigentlich so braucht.

In der aktuellen QTS 4.4.1 Version ist libvirt 1.2.19 mit Hypervisor QEMU 2.3.1 enthalten. Die Frage ist aber wie kommt man an diese Informationen? Am einfachsten man meldet sich mittels SSH am NAS an und geht mittels Busybox und dem Befehl virsh auf die Suche. Virsh ist ein mächtiges Kommandozeilen-Tool bzw. Shell zur Verwaltung von virtuellen Maschinen. Blöd nur, dass auf anhieb virsh nicht aufrufbar ist. Man muss zunächst zwei Umgebungsvariablen definieren:

export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/
export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/

Danach steht virsh direkt zum Aufrufen bereit, z. B. so:

virsh version

Werbeanzeigen

Einfachste Methode einen virtuellen Mac hochzuziehen

15 Juni 2019

Benötigt wird ein aktueller Intel-Rechner, z. B. ein Intel NUC, darauf installiert man ein aktuelles Debian, in diesem nutzt man dann QEMU um einen virtuellen Mac hochzuziehen.

Dazu benötigt man die Skripte von https://github.com/foxlet/macOS-Simple-KVM. Es werden alle nötigen Downloads direkt über Apples Wiederherstellungskonsole durchgeführt. Ein Tutorial beschreibt wie man das ganze einrichtet: https://passthroughpo.st/new-and-improved-mac-os-tutorial-part-1-the-basics/ und wie man Verfeinerungen in Bezug auf Netzwerk, Grafikkarte und Sound vornehmen kann: https://passthroughpo.st/mac-os-vm-guide-part-2-gpu-passthrough-and-tweaks/.

COM-Schnittstelle bei Windows Remote Desktop oder Virtuellen Maschinen

24 Mai 2019

Wer eine physische COM-Schnittstelle auf einem anderen Rechner mittels Remote-Desktop verfügbar machen möchte, muss folgendes beachten.

Zuerst muss man im Remote Desktop die Optionen einblenden, um beim Register Lokale Ressourcen, unten bei “Lokale Geräte und Ressourcen”, die Weiter-Schaltfläche anklicken zu können. Dort aktiviert man nun den Eintrag Ports.
Alternativ kann man auch in der betreffenden RDP-Datei den Eintrag redirectcomports:i:0 auf 1 setzen und speichern.

Wer nun die Verbindung zum Remoterechner herstellt wird vielleicht gleich im Geräte-Manager nachschauen, ob die COM-Schnittstelle unter “Anschlüsse (COM & LPT)” auch auftaucht. Doch da herrscht gähnende Leere. Tja, der Geräte-Manager ignoriert den COM-Port großzügig.

Der Port ist aber trotzdem verfügbar und kann mittels Powershell-Eingabeaufforderung mit diesem Befehl aufgelistet werden:

[System.IO.Ports.SerialPort]::GetPortNames()

Gemeldet wird dann z. B. COM1.

Wenn man bei virtuellen Maschinen mehr machen möchte, muss man Named Pipes benutzen und kann so RS232-Hardware vom Host direkt einer virtuellen Maschine zur Verfügung stellen. Realisiert wird dies durch PipeToCOM: https://github.com/mcmlxxix/PipeToCom. Diese Lösung hat natürlich den Vorteil ohne Remote Verbindung auszukommen. Jetzt wird es aber wieder kompliziert, denn wenn man eine Generation 2 VM in einem Hyper-V hat, dann gibt es keine COM-Ports mehr. Man kann allerdings mittels Powershell und SET-VMComPort COM1 aktivieren und darüber den Pfad für die Pipe setzen.

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.

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.

Sinnvolle Größen von virtuellen Maschinen in Verbindung mit Azure

5 Mai 2016

Wenn man mit virtuellen Maschinen in Azure arbeitet, gibt es mittlerweile eine Unzahl von Maschinen zur Auswahl. Für Westeuropa gibt es aktuell 63 verschiedene Konstellationen.

(Get-AzureRmVMSize -Location westeurope).length

Wenn man einen Überblick über die Welt haben möchte, dann kann man dies mittels diesem Aufruf bekommen:

Get-AzureRmLocation| % {$_.DisplayName; (Get-AzureRmVMSize -Location $_.location).length}

East Asia
39
Southeast Asia
49
Central US
49
East US
53
East US 2
49
West US
53
North Central US
35
South Central US
53
North Europe
53
West Europe
63
Japan West
29
Japan East
43
Brazil South
21

Wie sieht nun so ein VMSize-Eintrag aus? Holen wir uns also den ersten Eintrag:

(Get-AzureRmVMSize -Location westeurope)[0]

MaxDataDiskCount     : 1
MemoryInMB           : 768
Name                 : Standard_A0
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 20480

In diesem Artikel interessiert uns nur MemoryInMB und NumberOfCores.

Bei diesen Informationen stellt sich immer auch gleich die Frage nach dem Preis. Leider sind die Azure Billing APIs mit der RateCard-Info immer noch im Preview Status (https://msdn.microsoft.com/en-us/library/azure/mt218998.aspx). Auch gibt es noch keine Powershell-Cmdlets, so dass ich hier auf die normale HTML-Seite mit den Preisen verweise: https://azure.microsoft.com/de-de/pricing/details/virtual-machines/.

Bleiben wir bei West Europe, es gibt also 63 verschiedene VM-Größen. Aber welche Größen machen wirklich Sinn?

Grenzen wir den Zweck der VM ein, da wäre zunächst die Frage zu klären, ob man ein 32-Bit oder 64-Bit Betriebssystem darauf installieren möchte. Rein technisch kann man zwar 32-Bit Betriebssysteme auf VMs mit 12GB Arbeitsspeicher installieren, aber was macht dies für einen Sinn wenn man nur 4GB maximal nutzen kann?

Man kann mittels

Get-AzureRmVMSize -Location westeurope |where { $_.memoryinmb -le 4096  }

nun die in Frage kommenden VMs ermitteln. Zum Zeitpunkt dieses Artikels lieferte die Abfrage 10 Kandidaten: Standard_A0, Standard_A1, Standard_A2, Basic_A0, Basic_A1, Basic_A2, Standard_D1, Standard_D1_v2, Standard_DS1 und Standard_DS1_v2.

Worin unterscheiden sich nun Standard und Basic? Basic sind für Testserver gedacht, schnell hochfahren was ausprobieren und wegwerfen. Wer eine VM braucht die sinnvolle Tätigkeiten erfüllen soll, sollte Standard wählen.

Die Angaben über A,B,D,G usw. geben dann die Kategorie an, welche die VM im Sinne der Performance und Rechnerpower kategorisiert.

In diesem Zusammenhang muss man wissen, dass erst bei der Kategorie D und G SSDs als Festplatten zum Einsatz kommen. Allerdings ist bei SSDs zusätzlich noch wichtig, das diese nur temporär sind, wer dauerhaft den Inhalt der SSDs benötigt, der muss die DS*-Varianten verwenden.

Kommen wir nochmal zurück zum Arbeitsspeicher. Wer z. B. eine VM zum Ausprobieren möchte, wo ein 64-Bit Betriebssystem zum Einsatz kommen kann, der braucht mindestens 2GB an Arbeitsspeicher.

Dieser Aufruf listet alle in Frage kommenden Größen auf:

Get-AzureRmVMSize -Location westeurope |where { $_.memoryinmb -ge 2048  }

Momentan sind es 59 Stück.

Ein weiterer Faktor bei einer VM sind auch die Anzahl der Kerne. Eine schöne Auflistung, was die einzelnen Größen hergeben erhält man z. B. so:

Get-AzureRmVMSize -Location westeurope|sort numberofcores| Format-Table -GroupBy Numberofcores -Property Name,MemoryInMB, OSDiskSizeInMB, ResourceDiskSizeInMB, MaxDataDiskCount

Man erhält dadurch

   NumberOfCores: 1

Name            MemoryInMB OSDiskSizeInMB ResourceDiskSizeInMB MaxDataDiskCount
—-            ———- ————– ——————– —————-
Standard_D1           3584        1047552                51200                2
Basic_A1              1792        1047552                40960                2
Standard_D1_v2        3584        1047552                51200                2
Standard_DS1_v2       3584        1047552                 7168                2
Standard_DS1          3584        1047552                 7168                2
Basic_A0               768        1047552                20480                1
Standard_A1           1792        1047552                71680                2
Standard_A0            768        1047552                20480                1

   NumberOfCores: 2

Name             MemoryInMB OSDiskSizeInMB ResourceDiskSizeInMB MaxDataDiskCount
—-             ———- ————– ——————– —————-
Standard_G1           28672        1047552               393216                4
Standard_D2_v2         7168        1047552               102400                4
Standard_GS1          28672        1047552                57344                4
Standard_A2            3584        1047552               138240                4
Standard_D11_v2       14336        1047552               102400                4
Standard_DS11         14336        1047552                28672                4
Standard_DS2_v2        7168        1047552                14336                4
Standard_DS11_v2      14336        1047552                28672                4
Standard_DS2           7168        1047552                14336                4
Standard_D11          14336        1047552               102400                4
Standard_D2            7168        1047552               102400                4
Standard_A5           14336        1047552               138240                4
Basic_A2               3584        1047552                61440                4

Weiß man also wie viel Arbeitsspeicher und wie viel Kerne eine VM haben soll, dann kann man hiermit ermitteln was in Frage kommt:

Get-AzureRmVMSize -Location westeurope |where { ($_.memoryinmb -ge 2048 -and $_.memoryinmb -le 4096) -and ($_.numberofcores -le 2) }

MaxDataDiskCount     : 4
MemoryInMB           : 3584
Name                 : Standard_A2
NumberOfCores        : 2
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 138240

MaxDataDiskCount     : 4
MemoryInMB           : 3584
Name                 : Basic_A2
NumberOfCores        : 2
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 61440

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_D1
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 51200

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_D1_v2
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 51200

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_DS1
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 7168

MaxDataDiskCount     : 2
MemoryInMB           : 3584
Name                 : Standard_DS1_v2
NumberOfCores        : 1
OSDiskSizeInMB       : 1047552
ResourceDiskSizeInMB : 7168

Obige Liste stellt eine einfache Auswahl an Konfigurationen dar die für einfache Tests mit 64-Bit Betriebssystemen sinnvoll sind. Natürlich kann man mit Cores und Speicher und Performance immer nach oben gehen aber dies ist immer auch eine Frage der Kosten.

Neben den Kosten ist ein weiterer Aspekt der sinnvollen VM Größen im Zusammenhang mit Hyper-V. Wer in Zukunft im Hyper-V virtuelle Maschinen einrichtet, der sollte sich vielleicht auch mit den verfügbaren Größen der Azure VMs auseinandersetzen. Denn wenn später ein Umzug einer VM von Hyper-V nach Azure ansteht, ist es sinnvoll die Grundausrichtung der Hyper-VM bereits an möglichen Azure-VMs vorzunehmen, dann fällt einem der Umzug leichter. Hier hat bereits jemand diesen Gedanken: https://github.com/adbertram/Random-PowerShell-Work/blob/master/Azure/ConvertTo-AzureSize.ps1.

Festplatte bei virtuellem Rechner erweitern bzw. vergrößern

27 März 2016

Hier im Schnelldurchgang, um z. B. einem Rechner 10GB mehr zukommen zu lassen:

-Virtuellen Rechner offline nehmen
-dann auf dem Hyper-V

Resize-VHD –Path  PfadzuVHDXDatei -SizeBytes ((Get-VHD PfadzuVHDXDatei).Size + 10GB)

ausführen

-VM wieder hochfahren und dann die gewünscht Partition um die erweiterte Größe vergrößern. Dazu verwendet man die Datenträgererwaltung oder direkt diskmgmt.msc. Diese Operation könnte man auch per Powershell direkt nach obiger Erweiterung durchführen…

AzureResourceManager und die Hintergründe zu Switch-AzureMode

5 März 2016

Microsofts Azure wird nicht mehr verschwinden. Wer sich effektiv mit Azure beschäftigt, der sollte wie immer per Powershell die Sache angehen. Auf GUIs kann man sich in der Regel nicht verlassen, da diese einer gewissen Mode unterliegen. Aus diesem Grund wird in diesem Blog versucht so gut wie alles per Kommandozeile bzw. Powershell zu regeln.

Blöd nur, wenn sich nun aber die Powershell Cmdlets ebenso ändern und man keinen Plan hat warum, wieso und weshalb. So liest man oft von Switch-AzureMode oder von Azure Resource Manager (ARM). Hier ein Auszug einer Microsoft Dokumentation https://azure.microsoft.com/de-de/documentation/articles/virtual-machines-deploy-rmtemplates-powershell/:

Azure PowerShell ist derzeit in zwei Versionen verfügbar: 1.0 und 0.9.8. Wenn Sie bereits Skripts haben und diese nicht sofort ändern möchten, können Sie weiterhin Version 0.9.8 verwenden. Bei der Verwendung der Version 1.0 sollten Sie Ihre Skripts sorgfältig in Präproduktionsumgebungen testen, bevor Sie sie in der Produktionsumgebung einsetzen, um unerwartete Folgen zu vermeiden.

Cmdlet-Namen der Version 1.0 haben das Muster {Verb}-AzureRm{Nomen}, während Namen der Version 0.9.8 nicht Rm enthalten (z. B. „New-AzureRmResourceGroup“ statt „New-AzureResourceGroup“). Wenn Sie Azure PowerShell 0.9.8 verwenden, müssen Sie zunächst den Ressourcen-Manager-Modus aktivieren, indem Sie den Befehl Switch-AzureMode AzureResourceManager ausführen. Dieser Befehl ist in 1.0 nicht erforderlich.

Das ist alles schön und gut, aber das Web ist voll von alten Beispielen und Code-Snippets und manchmal wäre es ganz gut tiefergehende Infos zum Thema zu erhalten.

Mittlerweile wird auf einen speziellen Artikel verwiesen, der die neuen Möglichkeiten des Ressourcen-Manager-Model anschaulich darlegt: https://azure.microsoft.com/de-de/documentation/articles/resource-manager-deployment-model/

Wenn man zum Thema etwas recherchiert, dann kann man diesen Wiki-Eintrag in Github finden, der geht sehr ausführlich nochmal auf die Hintergrunde ein: https://github.com/Azure/azure-powershell/wiki/Deprecation-of-Switch-AzureMode-in-Azure-PowerShell

Es gibt sogar ein Script, welches automatisch virtuelle Maschinen vom Azure Service Management (ASM) Modell ins Azure Resource Mangement (ARM) Model migriert: https://github.com/fullscale180/asm2arm.

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.