VMDK-Dateien per Powershell in VHD / VHDX konvertieren

Bei einer Migration von VMWare auf Hyper-V in der man virtuelle Maschinen übernimmt, muss man die VMDK-Dateien der VMs in VHD bzw. VHDX-Dateien umwandeln. Es gibt natürlich hier Tools wie den Starwind V2V Converter – aber wenn man mehrere VMDKs hat ist so ein graphisches Tool in dem ich für jede einzeln das Programm durchklicken muss natürlich nichts. Dafür gibt es beim Microsoft Virtual Machine Converter 2.0 schöne Powershell-Befehle mit denen man das erledigen – und natürlich auch scripten – kann.

Nach der Installation öffnet man eine Powershell als Administrator

Dann muss man erstmal die Module importieren

Import-Module ‚C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1‘

danach kann konvertiert werden – z.B:

convertTo-MvmcVhd -SourceLiteralPath C:\Migration\sv-db.vmdk -DestinationLiteralPath d:\Hyper-V\VHDs -VhdType FixedHardDisk -VhdFormat vhdx

Der Name der VHDX-Datei ist der der VMDK-Datei – hier also sv-db. Abgelegt wird die in unserem Beispiel also die sv-db-vhdx im Ordner d:\Hyper-V\VHDs.

Aussehen wird das dann zum Beispiel so:

mvmc

Das ganze kann man natürlich auch scripten:

cd /d c:\Migration
Import-Module ‚C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1‘
gci -Filter *.vmdk | foreach {ConvertTo-MvmcVhd -SourceLiteralPath $_.Fullname -DestinationLiteralPath D:\Hyper-V\VHDs -VhdType FixedHardDisk -VhdFormat vhdx}

Hier wird erst in den Ordner gegangen in dem die VMDK-Dateien liegen – hier also c:\Migration. Danach wird das Cmdlet geladen. mit gci (Alias für get-childitem) werden alle VMDK-Dateien aufgelistet und in den Konvertierungsbefehl geschickt. Es werden dann nacheinander alle VMDK-Dateien in unserem Zielordner (hier d:\Hyper-V\VHDs) als VHDX-Dateien konvertiert abgelegt.

Danach können die Maschinen angelegt werden.

Nähere Infos zu den Powershell-Befehlen gibt es in dem MVMC_cmdlets.doc beim Download.

VMWare ESXi: „Es wurde kein Ziel für Coredumps konfiguriert. Derzeit können keine Coredumps für den Host gespeichert werden.“

Nach einem Update eines ESXi 5.1 auf 5.5 bekamm ich im VMWare vSphere Client diese Meldung angezeigt:

VMWareCoredumps1

Das Update hat die Partitons-IDs geändert und deshalb stimmt der Pfad in der Konfig nicht mehr. Das kann man leicht folgendermaßen ändern:

1) per SSH anmelden oder direkt am Server in die Shell
2) die aktuelle Konfiguration mittels

esxcfg-dumppart -l

anzeigen lassen.

3) Alle verfügbaren Partitonen für das Coredump anzeigen lassen

esxcfg-dumppart -f

4) Die angezeigte Partition als Dump-Partition konfigurieren (der Partitonsname fängt immer mit naa. an – den entsprechen anpassen)

esxcfg-dumppart -s partitionsname

z.B. wie in meinem Fall:

esxcfg-dumppart -s naa.600508e00000000071c560f22d78670a:7

5) nochmal die Konfiguration anzeigen lassen

esxcfg-dumppart -l

Jetzt müsste bei „Is Active“ bei der entsprechenden Partiton ein „Yes“ stehen und die Meldung im vSphere Client verschwinden.

Hier nochmal mein Fall als Beispiel:

VMWareCoredumps2

VMWare ESXi: VMDK umbenennen

Ich hatte das Problem in einer Umgebung ohne vCenter (ja sowas gibts) mehrere Windows Sever 2012 installieren zu müssen. Normaler weiße mit einem vCenter kein Problem – man macht eine Vorlage und stellt über diese die Server bereit. Ich habe also einen Server installiert und dann mit sysprep vorbereitet. Dann habe ich die Server in VMWare angelegt – ohne Festplatten. Danach habe ich die Festplatte meines „Vorlagen-Servers“ auf dem Datastore in jeden angelegten Server kopiert. Wegen der Optik muss aber die vmdk noch umbenannt werden:

Mit SSH auf dem ESXi anmelden.

dann in das entsprechende Verzeichnis gehen

cd /vmfs/volumes/NAME-DES-DATASTORES/NAME-DES-SERVERS/

dann umbenennen

vmkfstools -E alter-name.vmdk neuer-name.vmdk

Achtung: nur die .vmdk-Datei umbennen – die name-flat.vmdk-Datei wird automatisch mit umbennant.

Jetzt kann in die Festplatte in die VMs hinzugefügt werden.

Quelle: VMWare

VMWare ESXi: SSH aktivieren

Man muss ja öfters mal auf einen VMWare ESXi 5.x per SSH zugreifen. Standardmäßig ist dieser Dienst jedoch aus gutem Grund deaktiviert. Aktivieren lässt sich der Dienst direkt an der Konsole des Server – oder ganz einfach über den VMWare vSphere Client.

Den Dienst kann man im vShpere Client unter Konfiguration – Sicherheitsprofil – Dienste finden. Dort dann rechts oben auf Eigenschaften klicken. Dort kann man dann den Dienst aufwählen (in unserem Fall SSH) und starten – und natürlich auch wieder beenden

ssh-esxi

Ganz ohne zum Server gehen zu müssen 🙂

Installation der VMWare Tools bricht mit „interner Fehler 2203“ ab

Ich hatte das Problem, dass bei einem Update der VMWare Tools die Installation mit dem „internen Fehler 2203“ bzw. “internal error 2203″ abbricht. Die Deinstallation der Tools funktionierte – aber auch eine Neuinstallation der Tools scheiterte mit dem Fehler 2203 – der Windows Installer lief bei mir bei der Produktregistrierung nach den Audio-Treibern in den Fehler.

Den Fehler verursachten die Benutzervariablen TEMP und TMP. Diese beiden hab ich auf c:\temp gesetzt:

vmware-tools-umgebungsvariablen

Danach funktioniert die Installation 🙂

VMWare View: vCenter ändern

Ich hatte das Problem das sich in einer Umgebung mit VMWare View der vCenter-Server geändert hat. Ich habe versucht eine Anleitung für einen Umzug zu finden – leider ohne großen Erfolg. Hier wie ich es trotzdem hinbekommen habe:

Ausgangslage: VMWare View 5.1 auf eigenem Server intalliert. Desktop-Pools sind keine Linked-Clones. Neuer vCenter-Server installiert,die ESXi-Host verbunden und konfiguriert.

Problem: VMWare View kann zwar mehrere vCenter verwalten – aber die Desktop-Pools können nur einem vCenter zugeordnet sein – und das lässt sich nicht ändern. Also muss man hier ein wenig nachhelfen.

Dazu führt man auf dem View-Server folgende Schritte durch:

1) vCenter in View Manager eintragen

Als erstes muss der neue vCenter im View Manager eingetragen werden. Dazu navigiert man zu
View Konfiguration -> Server -> vCenter Server und fügt über Hinzufügen
mit Hilfe des Assistenten den neuen Server hinzu.

Dadurch wird im View LDAP das Objekt für den neuen vCenter angelegt.

2) Export der Einstellungen

Auch die ganzen Pool-Einstellungen stehen in diesem LDAP. Wir öffnen die VMWare PowerCLI Powershell und machen einen Export

vdmexport -v -f c:\view-export.ldif

3) Anpassen der Einstellungen

Als erstes rate ich dazu ein Backup der Datei zu erstellen. Danach können wir durch ersetzen der alten vCenter-ID durch die neue vCenter-ID die Konfiguration der Desktop-Pools anpassen.

Dazu öffnen wir die Datei in einem Editor – ich empfehle Notepad oder Notepad++.

Zuerst muss man die vCenter-Definitionen in der Datei suchen. Sie sehen so aus:

Der alte vCenter:

dn: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: abcd1234-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://alter-vCenter.test.local:443/sdk

Der neue vCenter

dn: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: efgh5678-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://neuer-vCenter.test.local:443/sdk

Der dn-Wert ist die ID des vCenters – in diesem Fall von unserem neuen Server also efgh5678-49cb-4fce-ae39-5dbcba9120d1.

Jetzt sucht man nach dem pae-VCDN-Wert der Desktop-Pools. Dafür sucht man mit der alten ID nach

pae-VCDN: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1

Hier müsste man die einzelnen Desktop-Pools finden. Jetzt kann man die ID einfach ersetzten.

Suchen nach:
pae-VCDN: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
Ersetzten durch:
pae-VCDN: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int

Ich empfehle hier keine „Alle Erstzen“ des Editors zu machen, sonder schön einzeln und manuell.

Danach speichern wir die Datei am besten unter c:\view-import.ldif ab.

4) Import der Einstellungen

Wir öffnen wieder die VMWare PowerCLI Powershell und machen den Import

vdmimport -f c:\view-import.ldif

Der Import ändern normalerweise nur Werte die geändert worden sind.

Danach im VMWare View Manager die Pools überprüfen – nach einem Browser-Refresh müssten die Pools den neuen vCenter-Server anzeigen.

Falls möglich jetzt noch den alten vCenter (wenn nicht eh schon) beenden und testen. Bei mir traten keine Probleme auf.

Das wars 🙂

Quelle: Link

Aufruf von “HostDatastoreSystem.QueryVmfsDatastoreCreateOptions” für Objekt “ha-datastoresystem” auf ESXi “XXX.XXX.XXX.XXX” ist fehlgeschlagen

Ich hatte das Problem, dass beim hinzufügen eines neuem Datastores – in meinem Fall ein frischer RAID-5-Festplatten-Verbund – folgender Fehler aufgetreten ist:

esxi_error_datastoresystem

Der Fehler Aufruf von “HostDatastoreSystem.QueryVmfsDatastoreCreateOptions” für Objekt “ha-datastoresystem” auf ESXi “XXX.XXX.XXX.XXX” ist fehlgeschlagen deutete auf ein Formatierungsproblem hin.

Zuerst sollte man im vSphere Client kontrollieren ob die Festplatte gemountet ist und welchen Laufzeitnamen die Fesplatte im System hat:

ESXiHostData1

Die Festplatte sollte keine Partitionen anzeigen.

Danach macht man eine SSH-Verbindung zum ESXi-Server auf und führt folgendes aus:

fdisk /dev/disks/mpx.vmhba1:C0:T1:L0

wobei /dev/disks/mpx.LAUFZEITNAME der Pfad zur Festplatte ist.

danach löschen wir mit d alle vorhandene Partitionen bis am Schluss die Meldung

No partition is defined yet! kommt

Danach schreiben wir mit w die Veränderung auf die Platte.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table

Im vSphere Client sollte jetzt nochmal eine erneute Prüfung veranlasst werden und danach sollte das Erstellung im vSphere-Client kein Problem mehr sein 🙂

ESXiHostData2

Die Installation des VMWare vCenter 4.1 bricht kurz vor dem Abschluss mit folgender Fehlermeldung ab: Error 25003.Setup Failed to create the VirtualCenter repository.

Falls man das vCenter 4.1 vom VMWare installiert und nicht die integrierte SQLServerExpress verwendet, sondern auf einen eigenen ODBC (für z.B. einen eigenen SQL Server), dann kann es vorkommen, dass das Setup mit dem Fehler „Error 25003.Setup Failed to create the VirtualCenter repository.“ abbricht.

Das Problem tritt vornehmlich bei Sprachversionen ungleich Englisch auf.
Wenn man in der ODBC-DSN-Verbindung folgende Änderungen durchführt sollte es klappen:

– change language of system messages to English
– uncheck Perform Translation For Character Data
– uncheck Use Regional Settings When Outputting Currency, Numbers, Dates, And Times

Die Sprache des ODBC´s muss also Englisch sein und keine Daten-Optionen aktiviert sein.

Viel Erfolg!