VMware-Forum

Hallo,

ich habe auf einem Server mit einer 500 GB Festplatte ein ESXi 4.0 U1 laufen, mit dem vSphere Client administriere ich das. Ich verstehe aber folgendes nicht:

Wenn ich im vSphere Client Datenspeicherbrowser die 2 Festplatten (kein RAID) meines ESXi ansehe, finde ich auf der zweiten HDD, die ich zum Sichern verwende, u.a. eine 30 GB große vmdk-Datei vor:



die ich kürzlich gesichert hatte, als ich meine VM heruntergefahren hatte.
Schön und gut, gehe ich aber mit Putty oder WinSCP auf das ESXi, finde ich dort nur eine ca. 100 GB große Datei:



und gar keine vmdk-Datei im Verzeichnis, wo ich die aktive VM-vmdk vermutet hätte.

Wie verhält sich denn das? Ist der Datenspeicherbrowser nur Augenwischerei?
Wie soll ich denn dann die vmdk-Datei sichern?

Gruß, Danke, franc

Der Datastorebrowser luegt.

Er zeigt vmdks nur dann korrekt an wenn diese defekt sind -


Normalerweise sieht man per winscp zB:

blabla.vmdk ... 1kb
blabla-flat.vmdk ... 100Gb

Datastorebrowser hingegen zeigt nur

blabla.vmdk ... 100Gb

allerdings mit der Groesse der blabla-flat.vmdk an.

Erst wenn die blabla.vmdk aus irgendeinem Grund defekt ist zeigt der Luegenbaron beide an.


Kurz und gut - zum sichern von vmdks ist der Datastorebrowser nur ganz bedingt geeignet.

Was die Designer sich dabei gedacht haben ist mir ein Raetsel.
Ich hab schon einen Feature-request im VMTN gepostet um dem Datastorebrowser abzugewoehnen die User fuer dumm zu halten ...

WAAAS?
Der lügt?

Also dass die vmdk's defekt sein sollten würde mich sehr wundern. Ich habe die Kiste(n) ordentlich runtergefahren, und mit dem Datenspeicherbrowser die vmdk's auf die andere Platte kopiert (per Kontextmenü). Ohne Zwischenfälle.

Außerdem müsste WinSCP dann auf jeden Fall auch lügen. Wenn ich nämlich die ganzen Sicherungsdateien zusammenzähle, die sich angeblich auf der zweiten Platte befinden, dann komme ich auf fast 1 TB, aber die Platte hat sicher nur 500 GB.

Irgendwas stimmt da nicht.

wo die Text-vmdk liegt kannst du doch in der vmx nachsehen

Winscp luegt nicht !

http://communities.vmware.com/message/1322248

Wie kann das aber sein, dass ich auf einer 500 GB Platte fast 1000 GB flat-vmdk's habe?

Also zumindest bei der Größe "flunkert" WinSCP ordentlich.
Die flat-vmdk's sind immer 107.374.182.400 Bytes groß.
Wie groß sind sie aber wirklich?
Und sichere ich die einfach dennoch, obwohl sie so groß angezeigt werden?

Anscheinend ist diese speckarme Minilinuxversion nicht in der Lage, die Größe von sehr großen Dateien zu ermitteln.
Sonst würde für die vmdk's nicht stereotyp immer 107.374.182.400 angegeben werden.

Das Problem besteht noch immer: die busybox zeigt für zu große Dateien stereotyp immer 107374182400 Bytes an.
Bin ich der einzige, bei dem das so ist?
Werden bei euch in der busybox etwa z.B. 30 GB Dateien in der Größe korrekt angezeigt?

Mach ich was falsch?

Ihr glaubt mir nicht? Hier bitte:

Jetzt habe ich testweise mal eine dieser 100 GB Dateien lokal runtergeladen, die ist aber tatsächlich 100 GB groß.

Ich habe im Verzeichnis (in der gemounteten HDD), in dem die laufenden VMs drin sind:

/vmfs/volumes/4b5b41e1-44433328-e0b2-001999714157

mit WinSCP (Rechtsklick und Eigenschaften) 322 GB ermittelt und im Verzeichnis (HDD), in dem ich die Backups habe:

/vmfs/volumes/4b5aceda-07b7ae5e-530f-001999714157

sind laut WinSCP 922 GB belegt. Ergibt insgesamt 1244 GB, bei zwei 500 GB Platten ist das doch Zauberei.
Wo ist denn da mein Denkfehler?

Gruß franc

PS.: Meiner Erfahrung nach erhalte ich in Foren meist dann keine Antwort, wenn die Probleme nicht nachvollziehbar hausgemacht sind. Das scheint wohl auch hier so zu sein...

Der Datastorebrowser lügt halt in beide Richtungen. Unschöne Sache, die hoffentlich im nächsten Update gefixt ist.

PS: Wenn ich mir die bisherigen Antworten im VMTN ansehe, scheint das wohl ein Feature zu sein. Jedenfalls gab es bisher keine einleuchtende Begründung für diesen Mißstand.

Ist das am Ende so, dass dieses sogenannte "thin" überhaupt nicht stimmt?
Also wenn ich eine Virtuelle Festplatte anlege und "Speicherplatz nach Bedarf zuteilen ..." (siehe Screenshot) ankreuze, wird dieses Anwachsen innerhalb der maximalen Grenzen nur im vSphere Databrowser angezeigt, in Wirklichkeit ist die vmdk immer gleich maximal groß?



Ich frage das vielleicht mal im englischen vmware Forum, wenn mir das hier keiner sagen kann.

Gute Frage, würde aber auf ein übles Problem und nachlässige Tests hindeuten.
Da wir ja ein "Inoffizielles, unabhängiges deutsches VMware-Forum" sind und wir keinerlei Unterstützung durch VMware bekommen, wirst du nur im communities.vmware.com/message/1322248 eine gesicherte Antwort erhalten können.
Ich würde den Link um deine Anfrage erweitern, die Antworten auf Ulli's Posting sind nicht so der Hit und seine Frage ist nach wie vor noch unbeantwortet.

Dayworker hat geschrieben:...Ich würde den Link um deine Anfrage erweitern....

Es ist ja doch nicht das selbe Problem, ich habe jetzt einen eigenen Thread aufgemacht:

http://communities.vmware.com/thread/256477

Ulli bemängelt ja, dass der DatastoreBrowser lügt, sobald eine vmdk kaputt ist.
Ich bemängle, dass der DatastoreBrowser auch schon vorher lügt und vorgaukelt, dass eine virtuelle Platte "Schnell" (thin) sei, in Wirklichkeit aber immer "Dauerhaft" (Thick) angelegt wird.
Und ich habe die Platten doch dünn angelegt, weil ich meine drei Server genau deswegen nämlich nochmal aufsetzen musste.

Ulli bemängelt ja, dass der DatastoreBrowser lügt, sobald eine vmdk kaputt ist.

- nein - genau umgekehrt - DatastoreBrowser lügt wenn eine vmdk anscheinend heile ist

continuum hat geschrieben:... DatastoreBrowser lügt wenn eine vmdk anscheinend heile ist

Ach so, ja, stimmt. Habs verwechselt.

Also jetzt ist mir das klarer geworden. Dank ausführlicher Antworten im (Groß)mutterforum:

http://communities.vmware.com/message/1480627

und dort dann eine gute Einführung:

http://kb.vmware.com/selfservice/micros ... Id=1015180

Quintessenz: Es liegt am VM-Filesystem, das WinSCP nicht so gut kennt. Die thin vmdk's werden unter WinSCP in ihrer kompletten reservierten Größe angezeigt und nicht in ihrem tatsächlichen Speicherbedarf.

Anders wäre es auch gar nicht gegangen, wie erwähnt wären sonst meine vmdks größer als die Platte