Ich habe einen Windows Server auf einem ESXi 5.5 laufen, aufgeteilt in C+D, mit C+D in je einer eigenen vmdk auf 2 unterschiedlichen Festplatten. Da D nicht wirklich wichtig ist, habe ich nur C mit Veeam gesichert. Jetzt habe ich es zurückgespielt. Das hat auch wunderbar funktioniert.
Wenn ich jetzt die vmdk mit D als vorhandene HD einbinden möchte, bekomme ich
"Ein allgemeiner Systemfehler ist aufgetreten: Unrecognized handle property identifier"
als Fehlermeldung und das wars.
Merkwürdig ist, dass sobald ich die vmdk hinzufüge, Thick Provision ausgewählt ist, die vmdk aber eindeutig für Thin Provision ausgewählt wurde.
Gibt es noch andere Möglichkeiten, die bestehende vmdk in die zurückgespielte Maschine einzufügen?
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
vmdk in virtuelle Maschine einbinden
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Hmmmm...
Zeig uns mal bitte ein Dateilisting von der CMD
Dazu den Inhalt der kleinen *.vmdk Dateien und das aktuelle vmware.log (Hochladen bei einem pastebin).
Frage:
Ist das nen aktuelles Backup oder Versionstechnisch irgendwie zurueck?
Gruss
Joerg
Zeig uns mal bitte ein Dateilisting von der CMD
Code: Alles auswählen
cd /vmfs/volumes/datastorename/vmname
ls -alhDazu den Inhalt der kleinen *.vmdk Dateien und das aktuelle vmware.log (Hochladen bei einem pastebin).
Frage:
Ist das nen aktuelles Backup oder Versionstechnisch irgendwie zurueck?
Gruss
Joerg
Vielen Dank für die Antwort. Welchen Logfile im speziellen meinst Du?
Es gibt keine Versionsüberschneidungen. Das letzte Backup ist von letzter Woche.
vmdk ist auch i.O. Ich habe es in der Zwischenzeit auf einen anderen Rechner gezogen und die Dateien extrahiert. Nur bevor ich den umständlichen Weg gehe, eine neue anzulegen und die Dateien wieder zurückzukopieren, stellt sich einfach die Frage, woran es liegen könnte.
Bei einem Instantrecovery von Veeam funktioniert es sofort und Laufwerk D wird sofort eingebunden. Leider liegt dann die zurückgesicherte Maschine nicht auf dem richtigen Datenträger.
Hier nun das Directorylisting von D:
vmdk vom alten Laufwerk D
vmdk von der wiederhergestellten Maschine
Es gibt keine Versionsüberschneidungen. Das letzte Backup ist von letzter Woche.
vmdk ist auch i.O. Ich habe es in der Zwischenzeit auf einen anderen Rechner gezogen und die Dateien extrahiert. Nur bevor ich den umständlichen Weg gehe, eine neue anzulegen und die Dateien wieder zurückzukopieren, stellt sich einfach die Frage, woran es liegen könnte.
Bei einem Instantrecovery von Veeam funktioniert es sofort und Laufwerk D wird sofort eingebunden. Leider liegt dann die zurückgesicherte Maschine nicht auf dem richtigen Datenträger.
Hier nun das Directorylisting von D:
Code: Alles auswählen
total 241926160
drwxr-xr-x 1 root root 1.1K Dec 29 19:20 .
drwxr-xr-t 1 root root 1.5K Aug 29 15:34 ..
-rw------- 1 root root 1.0T Dec 29 07:57 Festplatte 1TB-flat.vmdk
-rw------- 1 root root 554 Dec 29 07:51 Festplatte 1TB.vmdk
-rw------- 1 root root 0 May 26 2014 Festplatte 1TB.vmsd
-rw------- 1 root root 1.2K Dec 29 05:59 Festplatte 1TB.vmx
-rw------- 1 root root 269 May 26 2014 Festplatte 1TB.vmxf
vmdk vom alten Laufwerk D
Code: Alles auswählen
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=923afebe
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 2147483648 VMFS "Festplatte 1TB-flat.vmdk"
# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.deletable = "true"
ddb.geometry.cylinders = "133674"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "40a9d7688ef74d9e0f5b5c83932afdbd"
ddb.thinProvisioned = "1"
ddb.toolsVersion = "9354"
ddb.uuid = "60 00 D2 09 f2 80 5d 99-65 aa 77 59 86 11 b2 30"
ddb.virtualHWVersion = "8"vmdk von der wiederhergestellten Maschine
Code: Alles auswählen
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=3bdad56e
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 125829120 VMFS "Windows Server 2012 R2-flat.vmdk"
# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "7832"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "f7cbfa59fb2039ad1c364ecf3adad55e"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 D2 9e bf 67 64 d3-d9 cb f4 9a 8a 9f 0b fc"
ddb.virtualHWVersion = "10"Hmmm, irgendwie kann ich mich des Eindrucks nicht erwehren, dass hier nur Teile der Informationen zugegeben werden...
Also, der Deskriptor der 1TB-Festplatte sagt aus, dass es eine Thick-provisioned Platte ist. Bei Thin wuerde man VMFSSPARSE statt VMFS finden, meine ich.
Aber wieso gibt's da eine VM-Beschreibungsdatei "Festplatte 1TB.vmx"?
Dann faellt auf, dass die virtualHWVersion der beiden vmdk unterschiedlich ist (einmal 8, einmal 10). Was fuer eine Version ist die VM? Wurde vielleicht zwischendurch mal "Upgrade Virtual Hardware" angewaehlt? Hier waere das von irix gewuenschte vmware.log echt hilfreich gewesen. Das ist keine "spezielle Logdatei", sondern die liegt genau mit diesem Namen im Verzeichnis der die VM beschreibenden .vmx-Datei (welches mit an Sicherheit grenzender Wahrscheinlich eben NICHT die "Festplatte 1TB.vmx" sein duerfte, sondern vmtl eher "Windows Server 2012 R2.vmx"). Und falls da mehrere vmware*.log zu finden sein sollten, koennte man die immer noch zusammen-zippen (als Textdateien bleibt da nicht viel uebrig), und allesamt zur Einsicht irgendwo hochladen.
Also, der Deskriptor der 1TB-Festplatte sagt aus, dass es eine Thick-provisioned Platte ist. Bei Thin wuerde man VMFSSPARSE statt VMFS finden, meine ich.
Aber wieso gibt's da eine VM-Beschreibungsdatei "Festplatte 1TB.vmx"?
Dann faellt auf, dass die virtualHWVersion der beiden vmdk unterschiedlich ist (einmal 8, einmal 10). Was fuer eine Version ist die VM? Wurde vielleicht zwischendurch mal "Upgrade Virtual Hardware" angewaehlt? Hier waere das von irix gewuenschte vmware.log echt hilfreich gewesen. Das ist keine "spezielle Logdatei", sondern die liegt genau mit diesem Namen im Verzeichnis der die VM beschreibenden .vmx-Datei (welches mit an Sicherheit grenzender Wahrscheinlich eben NICHT die "Festplatte 1TB.vmx" sein duerfte, sondern vmtl eher "Windows Server 2012 R2.vmx"). Und falls da mehrere vmware*.log zu finden sein sollten, koennte man die immer noch zusammen-zippen (als Textdateien bleibt da nicht viel uebrig), und allesamt zur Einsicht irgendwo hochladen.
Also ich habe gerade einmal nachgeschaut.
Wenn ich das ganze mit Veeam als Instant Recovery zurückspiele (und da wird die vmdk mit Partition D mit der 1TB Festplatte erkannt und funktioniert) so steht in den Einstellungen ebendieser Platte "Thin Provision".
Ich habe vor einiger Zeit ein Update von 8->10 durchgeführt. Warum die vmdk das nicht mitgemacht hat weiß ich nicht, in den Einstellungen steht jedenfall VM-Version 10.
Ich habe gerade noch einmal versucht, die vorhandene vmdk hinzufügen, Fehlermeldung ist dieselbe. Eine vmware.log geschweige denn irgendein Logfile ist in dem Ordner der wiederhergestellten Version nicht.
Wenn ich das ganze mit Veeam als Instant Recovery zurückspiele (und da wird die vmdk mit Partition D mit der 1TB Festplatte erkannt und funktioniert) so steht in den Einstellungen ebendieser Platte "Thin Provision".
Ich habe vor einiger Zeit ein Update von 8->10 durchgeführt. Warum die vmdk das nicht mitgemacht hat weiß ich nicht, in den Einstellungen steht jedenfall VM-Version 10.
Ich habe gerade noch einmal versucht, die vorhandene vmdk hinzufügen, Fehlermeldung ist dieselbe. Eine vmware.log geschweige denn irgendein Logfile ist in dem Ordner der wiederhergestellten Version nicht.
Code: Alles auswählen
drwxr-xr-x 1 root root 1.8K Dec 31 13:10 .
drwxr-xr-t 1 root root 2.3K Dec 29 16:45 ..
-rw------- 1 root root 2.0G Dec 31 12:50 Windows Server 2012 R2-2e804e72.vswp
-rw------- 1 root root 60.0G Dec 31 13:10 Windows Server 2012 R2-flat.vmdk
-rw------- 1 root root 8.5K Dec 31 12:50 Windows Server 2012 R2.nvram
-rw------- 1 root root 537 Dec 31 12:50 Windows Server 2012 R2.vmdk
-rw------- 1 root root 43 Dec 29 15:27 Windows Server 2012 R2.vmsd
-rwx------ 1 root root 5.3K Dec 31 12:50 Windows Server 2012 R2.vmx
-rw------- 1 root root 0 Dec 31 12:50 Windows Server 2012 R2.vmx.lck
-rw------- 1 root root 3.3K Dec 29 15:26 Windows Server 2012 R2.vmxf
-rwx------ 1 root root 5.3K Dec 31 12:50 Windows Server 2012 R2.vmx~
-rw------- 1 root root 160.0M Dec 31 12:50 vmx-Windows Server 2012 R2-780160626-1.vswp
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Veeam Instant Recovery praesentiert die VM ueber einen NFS Mount. Vermutung... VMs auf NFS sind per Default Thinprovision.
Frage:
Kommt vSphere Client 5.5u2 oder groesser zum Einsatz? Weil sonst koenntest du die Eigenschaften ja mal garnicht bearbeiten. Das man damit vHW10 VMs bearbeiten kann ist ja "neu".
Falls du ein vCenter hast was passiert wenn du den WebClient nimmst? Was passiert wenn du mit dem vSphere Client 5.5u2 direkt auf den Host gehst um die Aenderung durchzufuehren?
Das vmware.log wird erst beim start der VM angelegt. Aber so weit kommst du ja garnicht weil du vorher deine 2. Platten anhaengen moechtest. Ich sehe das Problem auch eher auf Seite des Clients bzw. muesste Raten welchen Log man nun eigentich benoetigt. Der vSphere Client hat sein eigenesLog welches auf deinem PC liegt.
Ich wuerde die *.vmx Datei haendisch editieren und die 2. Platte eintragen und dann die VM DIREKT VON der Konsole starten
um die VIMID vorne zubekommen und dann
Nun wird auch das VMware Log der VM erstellt und man sollte lesen koennen was ihm warum nicht passt.
Gruss
Joerg
Frage:
Kommt vSphere Client 5.5u2 oder groesser zum Einsatz? Weil sonst koenntest du die Eigenschaften ja mal garnicht bearbeiten. Das man damit vHW10 VMs bearbeiten kann ist ja "neu".
Falls du ein vCenter hast was passiert wenn du den WebClient nimmst? Was passiert wenn du mit dem vSphere Client 5.5u2 direkt auf den Host gehst um die Aenderung durchzufuehren?
Das vmware.log wird erst beim start der VM angelegt. Aber so weit kommst du ja garnicht weil du vorher deine 2. Platten anhaengen moechtest. Ich sehe das Problem auch eher auf Seite des Clients bzw. muesste Raten welchen Log man nun eigentich benoetigt. Der vSphere Client hat sein eigenesLog welches auf deinem PC liegt.
Ich wuerde die *.vmx Datei haendisch editieren und die 2. Platte eintragen und dann die VM DIREKT VON der Konsole starten
Code: Alles auswählen
vim-cmd vmsvc/getallvms |grep -i "2012 R2"um die VIMID vorne zubekommen und dann
Code: Alles auswählen
vim-cmd vmsvc/power.on <VIMID>Nun wird auch das VMware Log der VM erstellt und man sollte lesen koennen was ihm warum nicht passt.
Gruss
Joerg
Veeam nimmt C aus dem Backup und D von der verbliebenen vmdk.
Laut den Einstellungen ist C Thick, D Thin.
Ja, es wird ein aktueller vSphere Client genutzt.
Kann das sein, dass die vmware.log nicht immer angelegt wird. Ich habe hier andere Maschinen, die sind etlichte Mal gestartet worden, und auch da befindet sich kein vmware.log, bei anderen hingegen schon.
Ich danke für die Unterstützung und werde im neuen Jahr irix Variante ausprobieren.
Laut den Einstellungen ist C Thick, D Thin.
Ja, es wird ein aktueller vSphere Client genutzt.
Kann das sein, dass die vmware.log nicht immer angelegt wird. Ich habe hier andere Maschinen, die sind etlichte Mal gestartet worden, und auch da befindet sich kein vmware.log, bei anderen hingegen schon.
Ich danke für die Unterstützung und werde im neuen Jahr irix Variante ausprobieren.
Zurück zu „vSphere 5.5 / ESXi 5.5“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 11 Gäste