Ich habe mehrere VMs über den Filemanagers des ESX importiert, dieses funktioniert auch einwandfrei. Leider habe ich ein Problem beim importieren einer VM (DC2003).
Diese VM legte ich an als 20GB Platte. irgendwann machte ich mal ein Snapshot. Später addete ich noch eine virtuelle 2te Platte und ich glaube ich machte nochmal ein Snapshot.
Nun hatte ich folgende Dateien:
[root@esx vmhba1:5:0:6]# ls
Win20032tehdd-f001.vmdk
Win20032tehdd-f002.vmdk
Win20032tehdd-f003.vmdk
Win20032tehdd-f004.vmdk
Win20032tehdd-f005.vmdk
Win20032tehdd-f006.vmdk
Win20032tehdd.vmdk
Win20032tehdd.vmdk-s001.REDO_a01604
Win20032tehdd.vmdk-s002.REDO_a01604
Win20032tehdd.vmdk-s003.REDO_a01604
Win20032tehdd.vmdk-s004.REDO_a01604
Win20032tehdd.vmdk-s005.REDO_a01604
Win20032tehdd.vmdk-s006.REDO_a01604
Win20032tehdd.vmdk.REDO_a01604
dc_ex2k3-flat.vmdk
dc_ex2k3.vmdk
dc_ex2k3.vmdk.REDO_a03572
nvram
nvram.sav
vmware.log
winNetEnterprise.vmx
winnetenterprise.png.sav
winnetenterprise.vmsn
winnetenterprise.vmx.sav
[root@esx vmhba1:5:0:6]#
Mein Problem ist, wenn ich unter Windows schaue ist die dc_ex2k3-flat 20 GB gross, unter dem Filemanager des ESX aber nur 1 MB. Und das geht mit den restlichen Dateien so weiter. Ausser das die Datei dc_ex2k3.vmdk.REDO_a03572 3,3 GB gross ist und die Datei Win20032tehdd.vmdk 10 GB gross ist.
Welche Datei muss ich denn jetzt importieren ??
Da sich die Dateien insgesamt auf 35 GB belaufen, würde ich gerne den Snapshot entfernen. Welche Dateien muss ich hier genau löschen, das ich den aktuellen Zustand !!! behalte und die Gesamtgröße dadurch kleiner wird.
Was ich auch kurios finde das die Datei dc_ex2k3.vmdk auch nur 1MB gross ist, und ich unter Windows die Datei dc_ex2k3-flat.vmdk (wo kommt diese Datei (flat?!) her mit 20GB angezeigt bekommt, aber unter Esx wieder nur 1MB.
Vielen Dank
Mfg
Marco
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!
Import von GSX 3.1 auf ESX 2.1.2 durch Redologs nicht möglic
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
Hi
ich hoffe mal fuer dich, dass du dein Temperament noch etwas zuegeln konntest und noch nichts geloescht hast.
Wenn es um Snapshots und Loeschen geht dann solltest du wissen statt glauben.
Hier habe ich mal ein paar Skizzen zu Snapshots gemacht: http://sanbarrow.com/basics-snapshot.html
Wenn du Dateien loeschst verwirfst du im besten Fall alle Aenderungen seit dem Zeitpunkt des letzten Snapshots - im unguenstigsten Fall loeschst du die Basis des Snapshots und stehst dann voellig ohne Festplatte da.
Nimm mal einen Texteditor und einen Eimer Neugier und oeffne die Dateien
Win20032tehdd.vmdk und dc_ex2k3.vmdk.
Fuer die VM sind diese Dateien die Festplatten. Fuer den Host sind diese beiden Dateien eine Art Inventurliste mit Wegbeschreibung.
In der dc_ex2k3.vmdk steht vermerkt wo sich deine komische *flat* Datei befindet. Die eigentlichen Daten befinden sich allein in der *flat*
Bei der anderen Platte ist es genauso - nur wurde hier der Kuchen in Stuecke aufgeteilt. Da steht dann zum Beispiel: Stueckanfang: 0 , Groesse: 2 000 000, Name: Rosinenkuchen-stueck3.torte, weitere Angaben: darf gegessen werden
Befassen wir uns mal mit der dc_ex2k3.vmdk
Im Anfang war das Wort und es sprach: Wizzard - mach mir eine schoene grosse Datei und zwar genau so eine, wie ich dir in dc_ex2k3.vmdk beschrieben habe. Der Wizzard las die Beschreibung, verstand seine Aufgabe und schrieb in aller Seelenruhe eine ungeheuer grosse Anzahl von Leerstellen und nannte diesen Erguss *flat*
Danach hast du die VM geweckt - aber sie war noch voellig orientierungslos und schickte erstmal das BIOS los - auf das dieses sich einen Ueberblick der Lage veschaffe. Das BIOS las in der dc_ex2k3.vmdk und erkannte dann in der *flat* eine Festplatte die es sich unter den Nagel reissen konnte. Das BIOS meldete dann dem Boss der Bande, dass es eine dc_ex2k3.vmdk gefunden habe und es jetzt eigentlich los gehen koenne.
Der Boss befahl also "booten" und von jener Zeit an wurde alles was du angestellt hast in die dc_ex2k3.vmdk geschrieben.
Die dc_ex2k3.vmdk musste alle Daten an die *flat* weiterreichen - aber den Boss interessierte das ueberhaupt nicht. Alles unterhalb der dc_ex2k3.vmdk war fuer den Boss ein Problem anderer Leute und mit diesen Details hielt er sich nicht auf.
Eines schoenen Tages betrachtetest du dein Werk und dachtest "Es ist gut" und dann soll man laut Handbuch auf den Snapshot-Button druecken. Was dann genau geschah das wusste wiederum nur das BIOS und die dc_ex2k3.vmdk. Diese einigten sich darauf, ab sofort nur noch in ein *REDO* zu schreiben und diese Mehrbelastung
nicht an die grosse Glocke zu haengen. Der Boss bekam also nichts davon mit dass das arme BIOS auf deine Anfragen nach (Festplattensektor) 523791 jetzt immer erst einmal im *REDO* nachschauen musste ob es da eine 523791 gab. Falls es da eine gab wurde dies vorgelesen, ansonsten musste halt die 523791 aus der *flat* genommen werden.
Das ging ein paar Wochen so gut und es wurden geniale Einfaelle geschrieben und dafuer dumme Ausfaelle geloescht - und in dieser ganzen Zeit hatte die *flat* Schreibpause musste aber weiterhin vorlesen.
Das *REDO* schrieb zB: in 523791 ein 'A' eintragen oder in *flat*-013759 das 'O' loeschen. Der Job mit dem 'A' wurde dabei als Zwischenloesung auf einem Schmierzettel direkt festgehalten - der 'O'- Job musste auf Tag X verschoben werden.
Heute - an Tag X wirst du ueber die *flat* und das *REDO* und ihre weitere |Zukunf richten:
Verschmelzung beider - Mord an dem *REDO* oder vielleicht doch lieber noch ein bisschen warten ???????
So das war die Vorgeschichte: - nun gehts es um die Wurscht
Du loeschst das *REDO* : der wirfst den Schmierzettel weg auf dem du notiert hattest, was du noch alles an der *flat* aendern wolltest. Du wolltest zB auf jeden Fall noch den genialen Einfall mit dem perpetuum mobile von vorgestern ins ordentliche Heft schreiben. Deine Kundenkartei hast du auch erst nach dem Snapshot angelegt - die steht also bis jetzt auch nur auf dem Schmierzettel Das heisst stand .... auch du jemine ... o nein ... o doch! !!!!!! Aber halt - dir bleibt wenigstens noch der Stand von vor 3 Wochen - immerhin brauchst du das Betriebsystem nicht noch mal zu bauen und du erinnerst dich an den Tag als du dachtest "Es ist gut"
Du loeschst die *flat* : du hast gehoert in der Galerie "ohne Zusammenhang" wuerden sie dir ein so chaotisches Geschreibsel wie es auf einmal in der *REDO* steht, als Modern Art aus den Fingern reissen.
Du erledigst die ausstehenden Jobs so wie es auf dem Schmierzettel stand und wirftst den Schmierzettel weg wenn alles getan ist.
Du bist unentschlossen und denkst: Ik kann mich gar nicht entscheiden - es ist alles so schoen bunt - hier"
Von diesen 4 Moeglichkeiten haben es nur 3 bis ins GUI geschafft.
Schon Kirk wusste - wenn man irgedwo einen Schalter mit der Aufschrift 'AUTODESTRUCT' einbaut, wird ihn innerhalb von 23 Minuten jemand druecken. Nimmt man einen Schalter mit Signalfarben und Warnhinweisen geht alles noch viel schneller.
Bei VMware heissen die verbliebenen Schalter:
Ik kann mich gar nicht entscheiden ------> Keep
Zurueck auf den Stand von vor 3 Wochen -------> Revert to snapshot
Alles ist toll- ich will es behalten ---------> Remove snapshot
Mit den Dateien passiert folgendes:
Keep ----> es aendert sich erstmal garnichts
Revert to snapshot -------> das *REDO* wird geloescht ohne noch einmal einen Blick darauf zu werfen
Remove snapshot -----> *REDO* und *flat* werden zusammen gebacken - bei dem Vorgang verschwindet das *REDO* nachdem es mit seinen Eintraegen die aelteren Eintraege der *flat* ueberschrieben hat.
So mal ein bisschen zum selber denken:
Man macht einen Snapshot eiener 30GB Datenplatte und formatiert diese anschliessend - wie gross kann danach das *REDO*
sein?
Was kann passieren wenn man ein 30kb grosses *REDO* einfach loescht -? Diese 30kb sind eventuell nur ein paar htmls die im Browsercache geschrieben wurden - die Aenderung am System ist hier so unbedeutend das man vielleicht ueberhaupt nichts davon merkt.
In diesen laecherlichen 30kb koennen aber auch genauso gut die boot.ini oder die lilo.conf gestanden haben - wenn man diese 30kb loescht kann das Sustem anschliessend unbrauchbar sein.
Was passiert wenn man die vmdk loescht und *flat* und *REDO* behaelt?
Die VM ist erst einmal nicht mehr startbar weil sie alle Erinnerungen an die Festplatte verloren hat. Mit etwas tuefteln kann man sich die Inventarliste der einzelnen Festplattemstuecke aber von Hand selber wieder neu erstellen.
das sollte - hoffe ich jedenfalls - dich erst einmal vor einem Tobsuchtsanfall mit anschliessender Niedergeschlagenheit bewahren.
Bei dieser Sache kann wirklich EIN dummer Klick die Arbeit von Monaten zerstoeren . So ich klick jetzt auf Absenden
Ulli
ich hoffe mal fuer dich, dass du dein Temperament noch etwas zuegeln konntest und noch nichts geloescht hast.
Wenn es um Snapshots und Loeschen geht dann solltest du wissen statt glauben.
Hier habe ich mal ein paar Skizzen zu Snapshots gemacht: http://sanbarrow.com/basics-snapshot.html
Wenn du Dateien loeschst verwirfst du im besten Fall alle Aenderungen seit dem Zeitpunkt des letzten Snapshots - im unguenstigsten Fall loeschst du die Basis des Snapshots und stehst dann voellig ohne Festplatte da.
Nimm mal einen Texteditor und einen Eimer Neugier und oeffne die Dateien
Win20032tehdd.vmdk und dc_ex2k3.vmdk.
Fuer die VM sind diese Dateien die Festplatten. Fuer den Host sind diese beiden Dateien eine Art Inventurliste mit Wegbeschreibung.
In der dc_ex2k3.vmdk steht vermerkt wo sich deine komische *flat* Datei befindet. Die eigentlichen Daten befinden sich allein in der *flat*
Bei der anderen Platte ist es genauso - nur wurde hier der Kuchen in Stuecke aufgeteilt. Da steht dann zum Beispiel: Stueckanfang: 0 , Groesse: 2 000 000, Name: Rosinenkuchen-stueck3.torte, weitere Angaben: darf gegessen werden
Befassen wir uns mal mit der dc_ex2k3.vmdk
Im Anfang war das Wort und es sprach: Wizzard - mach mir eine schoene grosse Datei und zwar genau so eine, wie ich dir in dc_ex2k3.vmdk beschrieben habe. Der Wizzard las die Beschreibung, verstand seine Aufgabe und schrieb in aller Seelenruhe eine ungeheuer grosse Anzahl von Leerstellen und nannte diesen Erguss *flat*
Danach hast du die VM geweckt - aber sie war noch voellig orientierungslos und schickte erstmal das BIOS los - auf das dieses sich einen Ueberblick der Lage veschaffe. Das BIOS las in der dc_ex2k3.vmdk und erkannte dann in der *flat* eine Festplatte die es sich unter den Nagel reissen konnte. Das BIOS meldete dann dem Boss der Bande, dass es eine dc_ex2k3.vmdk gefunden habe und es jetzt eigentlich los gehen koenne.
Der Boss befahl also "booten" und von jener Zeit an wurde alles was du angestellt hast in die dc_ex2k3.vmdk geschrieben.
Die dc_ex2k3.vmdk musste alle Daten an die *flat* weiterreichen - aber den Boss interessierte das ueberhaupt nicht. Alles unterhalb der dc_ex2k3.vmdk war fuer den Boss ein Problem anderer Leute und mit diesen Details hielt er sich nicht auf.
Eines schoenen Tages betrachtetest du dein Werk und dachtest "Es ist gut" und dann soll man laut Handbuch auf den Snapshot-Button druecken. Was dann genau geschah das wusste wiederum nur das BIOS und die dc_ex2k3.vmdk. Diese einigten sich darauf, ab sofort nur noch in ein *REDO* zu schreiben und diese Mehrbelastung
nicht an die grosse Glocke zu haengen. Der Boss bekam also nichts davon mit dass das arme BIOS auf deine Anfragen nach (Festplattensektor) 523791 jetzt immer erst einmal im *REDO* nachschauen musste ob es da eine 523791 gab. Falls es da eine gab wurde dies vorgelesen, ansonsten musste halt die 523791 aus der *flat* genommen werden.
Das ging ein paar Wochen so gut und es wurden geniale Einfaelle geschrieben und dafuer dumme Ausfaelle geloescht - und in dieser ganzen Zeit hatte die *flat* Schreibpause musste aber weiterhin vorlesen.
Das *REDO* schrieb zB: in 523791 ein 'A' eintragen oder in *flat*-013759 das 'O' loeschen. Der Job mit dem 'A' wurde dabei als Zwischenloesung auf einem Schmierzettel direkt festgehalten - der 'O'- Job musste auf Tag X verschoben werden.
Heute - an Tag X wirst du ueber die *flat* und das *REDO* und ihre weitere |Zukunf richten:
Verschmelzung beider - Mord an dem *REDO* oder vielleicht doch lieber noch ein bisschen warten ???????
So das war die Vorgeschichte: - nun gehts es um die Wurscht
Du loeschst das *REDO* : der wirfst den Schmierzettel weg auf dem du notiert hattest, was du noch alles an der *flat* aendern wolltest. Du wolltest zB auf jeden Fall noch den genialen Einfall mit dem perpetuum mobile von vorgestern ins ordentliche Heft schreiben. Deine Kundenkartei hast du auch erst nach dem Snapshot angelegt - die steht also bis jetzt auch nur auf dem Schmierzettel Das heisst stand .... auch du jemine ... o nein ... o doch! !!!!!! Aber halt - dir bleibt wenigstens noch der Stand von vor 3 Wochen - immerhin brauchst du das Betriebsystem nicht noch mal zu bauen und du erinnerst dich an den Tag als du dachtest "Es ist gut"
Du loeschst die *flat* : du hast gehoert in der Galerie "ohne Zusammenhang" wuerden sie dir ein so chaotisches Geschreibsel wie es auf einmal in der *REDO* steht, als Modern Art aus den Fingern reissen.
Du erledigst die ausstehenden Jobs so wie es auf dem Schmierzettel stand und wirftst den Schmierzettel weg wenn alles getan ist.
Du bist unentschlossen und denkst: Ik kann mich gar nicht entscheiden - es ist alles so schoen bunt - hier"
Von diesen 4 Moeglichkeiten haben es nur 3 bis ins GUI geschafft.
Schon Kirk wusste - wenn man irgedwo einen Schalter mit der Aufschrift 'AUTODESTRUCT' einbaut, wird ihn innerhalb von 23 Minuten jemand druecken. Nimmt man einen Schalter mit Signalfarben und Warnhinweisen geht alles noch viel schneller.
Bei VMware heissen die verbliebenen Schalter:
Ik kann mich gar nicht entscheiden ------> Keep
Zurueck auf den Stand von vor 3 Wochen -------> Revert to snapshot
Alles ist toll- ich will es behalten ---------> Remove snapshot
Mit den Dateien passiert folgendes:
Keep ----> es aendert sich erstmal garnichts
Revert to snapshot -------> das *REDO* wird geloescht ohne noch einmal einen Blick darauf zu werfen
Remove snapshot -----> *REDO* und *flat* werden zusammen gebacken - bei dem Vorgang verschwindet das *REDO* nachdem es mit seinen Eintraegen die aelteren Eintraege der *flat* ueberschrieben hat.
So mal ein bisschen zum selber denken:
Man macht einen Snapshot eiener 30GB Datenplatte und formatiert diese anschliessend - wie gross kann danach das *REDO*
sein?
Was kann passieren wenn man ein 30kb grosses *REDO* einfach loescht -? Diese 30kb sind eventuell nur ein paar htmls die im Browsercache geschrieben wurden - die Aenderung am System ist hier so unbedeutend das man vielleicht ueberhaupt nichts davon merkt.
In diesen laecherlichen 30kb koennen aber auch genauso gut die boot.ini oder die lilo.conf gestanden haben - wenn man diese 30kb loescht kann das Sustem anschliessend unbrauchbar sein.
Was passiert wenn man die vmdk loescht und *flat* und *REDO* behaelt?
Die VM ist erst einmal nicht mehr startbar weil sie alle Erinnerungen an die Festplatte verloren hat. Mit etwas tuefteln kann man sich die Inventarliste der einzelnen Festplattemstuecke aber von Hand selber wieder neu erstellen.
das sollte - hoffe ich jedenfalls - dich erst einmal vor einem Tobsuchtsanfall mit anschliessender Niedergeschlagenheit bewahren.
Bei dieser Sache kann wirklich EIN dummer Klick die Arbeit von Monaten zerstoeren . So ich klick jetzt auf Absenden
Ulli
Also erstmal besten Dank für die ausfürliche Erklärung und das morgens um halb 5. HUT AB !!!!!!!!
Dank deiner Erklärung machte ich ein Remove Snapshot und alles wunderbar.
Jetzt habe ich folgende Dateien:
[root@esx dc_ex2k3]# ls -l
total 10485814
drwxr-xr-x 1 root root 512 Oct 2 11:57 NetworkService
-rwxr-xr-x 1 root root 5120 Aug 12 23:16 Thumbs.db
-rwxr-xr-x 1 root root 2147221504 Oct 2 10:48 Win20032tehdd-f001.vmd
k
-rwxr-xr-x 1 root root 2147221504 Oct 2 10:48 Win20032tehdd-f002.vmd
k
-rwxr-xr-x 1 root root 2147221504 Oct 2 10:48 Win20032tehdd-f003.vmd
k
-rwxr-xr-x 1 root root 2147221504 Aug 25 16:05 Win20032tehdd-f004.vmd
k
-rwxr-xr-x 1 root root 2147221504 Oct 2 07:01 Win20032tehdd-f005.vmd
k
-rwxr-xr-x 1 root root 1310720 Oct 2 10:48 Win20032tehdd-f006.vmdk
-rwxr-xr-x 1 root root 577 Oct 2 07:05 Win20032tehdd.vmdk
-rwxr-xr-x 1 root root 0 Oct 2 10:48 dc_ex2k3-flat.vmdk
-rwxr-xr-x 1 root root 352 Oct 2 07:05 dc_ex2k3.vmdk
-rwxr-xr-x 1 root root 8664 Oct 2 10:48 nvram
-rwxr-xr-x 1 root root 37190 Oct 2 10:48 vmware.log
-rwxr-xr-x 1 root root 1611 Oct 2 07:01 winNetEnterprise.vmx
[root@esx dc_ex2k3]#
Soweit so gut.
Das importieren der Win20032tehdd.vmdk zum Esx klappt super, aber die Hauptdatei dc_ex2k3-flat.vmdk zeigt mir unter dem Filemanager des ESX nur 1MB Dateigrösse. Diese Datei ist aber 20GB gross.
Und so kann ich diese Datei nicht umwandeln. OJE !
Die Frage die sich hier stellt, warum zeigt er mir nur 1MB an ?
Hiermal die Auszüge aus der dc_ex2k3-flat.vmdk:
# Disk DescriptorFile
version=1
CID=6a4aa4ee
parentCID=ffffffff
createType="monolithicFlat"
# Extent description
RW 41943040 FLAT "dc_ex2k3-flat.vmdk" 0
# The Disk Data Base
#DDB
ddb.toolsVersion = "5152"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "2610"
ddb.virtualHWVersion = "3"
Und den Auszug aus der Win20032tehdd.vmdk :
# Disk DescriptorFile
version=1
CID=987824e9
parentCID=ffffffff
createType="twoGbMaxExtentFlat"
# Extent description
RW 4193792 FLAT "Win20032tehdd-f001.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f002.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f003.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f004.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f005.vmdk" 0
RW 2560 FLAT "Win20032tehdd-f006.vmdk" 0
# The Disk Data Base
#DDB
ddb.virtualHWVersion = "3"
ddb.geometry.cylinders = "1305"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.toolsVersion = "5152"
Bitte um Hilfe
Vielen Dank
Gruß
Marco
Dank deiner Erklärung machte ich ein Remove Snapshot und alles wunderbar.
Jetzt habe ich folgende Dateien:
[root@esx dc_ex2k3]# ls -l
total 10485814
drwxr-xr-x 1 root root 512 Oct 2 11:57 NetworkService
-rwxr-xr-x 1 root root 5120 Aug 12 23:16 Thumbs.db
-rwxr-xr-x 1 root root 2147221504 Oct 2 10:48 Win20032tehdd-f001.vmd
k
-rwxr-xr-x 1 root root 2147221504 Oct 2 10:48 Win20032tehdd-f002.vmd
k
-rwxr-xr-x 1 root root 2147221504 Oct 2 10:48 Win20032tehdd-f003.vmd
k
-rwxr-xr-x 1 root root 2147221504 Aug 25 16:05 Win20032tehdd-f004.vmd
k
-rwxr-xr-x 1 root root 2147221504 Oct 2 07:01 Win20032tehdd-f005.vmd
k
-rwxr-xr-x 1 root root 1310720 Oct 2 10:48 Win20032tehdd-f006.vmdk
-rwxr-xr-x 1 root root 577 Oct 2 07:05 Win20032tehdd.vmdk
-rwxr-xr-x 1 root root 0 Oct 2 10:48 dc_ex2k3-flat.vmdk
-rwxr-xr-x 1 root root 352 Oct 2 07:05 dc_ex2k3.vmdk
-rwxr-xr-x 1 root root 8664 Oct 2 10:48 nvram
-rwxr-xr-x 1 root root 37190 Oct 2 10:48 vmware.log
-rwxr-xr-x 1 root root 1611 Oct 2 07:01 winNetEnterprise.vmx
[root@esx dc_ex2k3]#
Soweit so gut.
Das importieren der Win20032tehdd.vmdk zum Esx klappt super, aber die Hauptdatei dc_ex2k3-flat.vmdk zeigt mir unter dem Filemanager des ESX nur 1MB Dateigrösse. Diese Datei ist aber 20GB gross.
Und so kann ich diese Datei nicht umwandeln. OJE !
Die Frage die sich hier stellt, warum zeigt er mir nur 1MB an ?
Hiermal die Auszüge aus der dc_ex2k3-flat.vmdk:
# Disk DescriptorFile
version=1
CID=6a4aa4ee
parentCID=ffffffff
createType="monolithicFlat"
# Extent description
RW 41943040 FLAT "dc_ex2k3-flat.vmdk" 0
# The Disk Data Base
#DDB
ddb.toolsVersion = "5152"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "2610"
ddb.virtualHWVersion = "3"
Und den Auszug aus der Win20032tehdd.vmdk :
# Disk DescriptorFile
version=1
CID=987824e9
parentCID=ffffffff
createType="twoGbMaxExtentFlat"
# Extent description
RW 4193792 FLAT "Win20032tehdd-f001.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f002.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f003.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f004.vmdk" 0
RW 4193792 FLAT "Win20032tehdd-f005.vmdk" 0
RW 2560 FLAT "Win20032tehdd-f006.vmdk" 0
# The Disk Data Base
#DDB
ddb.virtualHWVersion = "3"
ddb.geometry.cylinders = "1305"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.toolsVersion = "5152"
Bitte um Hilfe
Vielen Dank
Gruß
Marco
Achso, noch folgendes, versuche ich die VM über die vmkfstools zu importieren bekomme ich folgende Fehlermeldung:
[root@esx dc_ex2k3]# vmkfstools -i dc_ex2k3.vmdk //vmfs/vmhba1\:5\:0\:6/dc2003.dsk
DiskLib_Open() failed. The file specified is not a virtual disk. (13)
[root@esx dc_ex2k3]# vmkfstools -i dc_ex2k3-flat.vmdk //vmfs/vmhba1\:5\:0\:6/dc2003.dsk
DiskLib_Open() failed. The file specified is not a virtual disk. (13)
[root@esx dc_ex2k3]#
Gruß
Marco
[root@esx dc_ex2k3]# vmkfstools -i dc_ex2k3.vmdk //vmfs/vmhba1\:5\:0\:6/dc2003.dsk
DiskLib_Open() failed. The file specified is not a virtual disk. (13)
[root@esx dc_ex2k3]# vmkfstools -i dc_ex2k3-flat.vmdk //vmfs/vmhba1\:5\:0\:6/dc2003.dsk
DiskLib_Open() failed. The file specified is not a virtual disk. (13)
[root@esx dc_ex2k3]#
Gruß
Marco
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
Hi
das die dc_ex2k3-flat.vmdk nicht als virtuelle Disk durchgeht entspricht der Logik das die VMs die Platten ueber einen "logischen Punkt" - ich weiss nicht wie ich das sonst ausdruecken soll - ansprechen. Die VMs verhandeln mit der Descriptorfile - die Details sind dann ein Problem anderer Leute.
Bei der dc_ex2k3.vmdk muss jetzt irgendwas sein was vom ESX ausgesehen nicht seiner Definition einer virtuellen Platte entspricht.
Falls ich selber jemals an einem ESX sitzen sollte wuerde ich als Workaround wohl per vmware-vdiskmanager die dc_ex2k3.vmdk in eine "twoGbMaxExtentSparse" - disk konvertieren und probieren, diese zu verfuettern.
Aber es geht wahrscheinlich auch noch viel einfacher - vielleicht reicht es ja schon die Datei mal im Unixformat neu zu speichern. Vielleicht ist auch einfach nur eine Datei-extension in Gross-buchstaben die klein sein sollte.
Vielleicht wuerde mir was auffallen wenn ich davor saesse - so weiss ich auch nicht wonach ich fragen sollte.
Ich sehe gerade noch - in der dc_ex2k3.vmdk sind die ddb-Eintraege nicht in der normalen Reihenfolge - vielleicht hilft es ja schon das mal wieder zu sortieren.
Vielleicht hilft auch ddb.toolsVersion = "0" auszuprobieren.
Ist der Header der dc_ex2k3-flat.vmdk in Ordnung?
Hast du schon mal probiert die beiden files umzubenennen? Achtung -- wenn du das ausprobierst muust du auch in der descriptorfile den Link aendern.
Die letzten Zeilen sind etwas unsortiert - ich schreibe nur immer wieder auf, was mir einfaellt waehrend ich hier den Keller entruempel ...
das die dc_ex2k3-flat.vmdk nicht als virtuelle Disk durchgeht entspricht der Logik das die VMs die Platten ueber einen "logischen Punkt" - ich weiss nicht wie ich das sonst ausdruecken soll - ansprechen. Die VMs verhandeln mit der Descriptorfile - die Details sind dann ein Problem anderer Leute.
Bei der dc_ex2k3.vmdk muss jetzt irgendwas sein was vom ESX ausgesehen nicht seiner Definition einer virtuellen Platte entspricht.
Falls ich selber jemals an einem ESX sitzen sollte wuerde ich als Workaround wohl per vmware-vdiskmanager die dc_ex2k3.vmdk in eine "twoGbMaxExtentSparse" - disk konvertieren und probieren, diese zu verfuettern.
Aber es geht wahrscheinlich auch noch viel einfacher - vielleicht reicht es ja schon die Datei mal im Unixformat neu zu speichern. Vielleicht ist auch einfach nur eine Datei-extension in Gross-buchstaben die klein sein sollte.
Vielleicht wuerde mir was auffallen wenn ich davor saesse - so weiss ich auch nicht wonach ich fragen sollte.
Ich sehe gerade noch - in der dc_ex2k3.vmdk sind die ddb-Eintraege nicht in der normalen Reihenfolge - vielleicht hilft es ja schon das mal wieder zu sortieren.
Vielleicht hilft auch ddb.toolsVersion = "0" auszuprobieren.
Ist der Header der dc_ex2k3-flat.vmdk in Ordnung?
Hast du schon mal probiert die beiden files umzubenennen? Achtung -- wenn du das ausprobierst muust du auch in der descriptorfile den Link aendern.
Die letzten Zeilen sind etwas unsortiert - ich schreibe nur immer wieder auf, was mir einfaellt waehrend ich hier den Keller entruempel ...
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste