Seltsames verhalten mit Snapshot

[UrsDerBär]

Hallo Zusammen,

Habe bei einem Test wohl müll gebaut, das gute ist aber, die VM läuft goldig. Noch

Was hab ich gemacht:
- Eine VM mit Snapshots aus dem Inventory entfernt
- Den Ordner der VM auf meine lokale Maschine kopiert
---> Alle Snapshots so gross wie die eigentliche Platte auf meiner Windows-Storage
- die VM wieder ins Inventory aufgenommen
- Alle Snapshots gelöscht

Nun wird mir im Datastorebrowser die Snapshots bzw. die üblichen Pseudonamen immer noch angezeigt. Nicht jedoch im Snapshotmanager. Sprich sie wurden nicht gelöscht. Auch die vmsd ist noch vorhanden.

in der VMX steht:
scsi0:0.fileName = "Name-000001.vmdk"

Datastore ist ein iSCSI-Storage

- Wie gehe ich nun am besten vor bzw. was genau ist das kaputt oder eben nicht?
- Welche Dateien kann ich löschen? Wie lösche ich sie? der Datastore-Browser erzählt eh nur käse

Das gute ist die VM läuft tadellos . soll natürlich So bleiben.

Grüsse und Dankeschön...

[continuum]

guck dir das besser mit winscp an.

Aber bevor du irgendwas loeschst - guck dir die snapshots genau an.
wenn 000001.vmdk in der vmx steht heisst das noch lange nicht das du alles hoeher als 000001.vmdk loeschen kannst.
Die snapshots muessen nicht linear durchnumeriert sein !

Wenn du unsicher bist - zip alle kleinen text-vmdks zusammen mit der vmx und lad sie bei
http://ifile.it hoch -dann gucke ich mal durch

[UrsDerBär]

Hi,

Dankeschön... Nun ich würde die Dinger gerne hochladen, aber irgendwie hab ich noch kein kopierrecht via winscp. Habe einen neuen benutzer angelegt und ihn in die gleichen Gruppen geworfen wie root, muss ich noch etwas tun? Auf die schnelle nix bei google gefunden.

Hab übrigens auch die Festplatte vergrössert... Die 0001er zeigt er mit der neuen grösse an. Die anderen mit der alten.

Grüsse und Dankeschön

[continuum]

Das ist ja schlau : bei problemen mit snapshots schnell nochmal die Platte vergroessern

Ich habe hier root-logon bei ssh erlaubt - dann ist das alles kein problem mit winscp

Ansonsten kommst du vielleicht per web weiter - da gibt es doch diesen web-based datastore-browser

[mangold]

Ich habe hier root-logon bei ssh erlaubt - dann ist das alles kein problem mit winscp

das ist das Erste was sich ein Prüfer anschaut ....aber ich mach das auch so

[continuum]

ein Prüfer ???

[UrsDerBär]

Hello...

I know, das war schlau. Aaaber ich hatte es ehrlich gesagt erst im nachhinein gemerkt, dass er die Snapshots gar nicht gelöscht hatte, weil ich nach der Vergrösserung wieder ne Kopie ziehen wollte. Wurde doch auch etwas nervös nachher.

Also ich hab auch mal SSH Zugriff für root aktiviert, da er mir partout keine erweiterten Rechte für Disks/Volumes für die Gruppe root akzeptieren möchte. Und nach jeder erstellten VM's die Rechte ändern ist mir auch etwas lästig.

Anbei der Link: http://ifile.it/nj5o39z/SBS.zip
Key per PN

Grüsse und Danke!

[continuum]

Au weia
das ist ja irre

Was bei dir wie snapshots aussieht sind gar keine - das sind normale vmdks.

Schick mal die vmware.logs die du noch hast und eine Dateiliste mit Groessenangaben.

Also das ist die komischste VM die ich je gesehen habe ....

Snapshots ohne parentfilename hint dafuer aber mit Geometry angaben ...

Hat vielleicht irgendein Spassvogel an den vmdks herum editiert - deine vmdks widersprechen alle Namenskonventionen die VMware selbst oder die meisten user befolgen wuerden ...

Interessant - schick mal deine Telefonnummer per PM - dann ruf ich mal an

[UrsDerBär]

Schönen Abend

Wie lustig, was für ein Ehre...

Kann dir gerne telefonisch erklären wie das ganze ablief, eigentlich ganz simpel, eigentlich so wie oben beschrieben. Meine Modifikationen und kopieraktionen habe ich immer im ausgeschaltetem Zustand vorgenommen.

Die ganze Geschichte der VM:
1. Vm erstellt, ein paar Snapshots während der Grundkonfig
2. Alle Snapshots gelöscht via Snapshot-Manager ---> War erfolgreich, keine Snapshots mehr im DS-Browser
3. Wieder einen Snapshot genommen
4. Diverse Modifikationen vorgenommen
5. Snapshot genommen
6. Grundsätzliche Konfig abgeschlossen, will Sicherung machen via Datastore-Browser, mag er allerdings nicht mit den Snapshots. Die wollte ich aber mitsichern.
7. Die VM aus dem Inventory entfernt, dauerte ewig
8. Die beiden Snapshots waren plötzlich beide 40GB gross gemäss DS-Browser (vorher 4 und 16)
9. Gesichert auf meinen lokalen PC, beide Snapshots + die Festplatte haben identische grössen --> 60 GB.
10. Wiederaufnahme der VM in das Inventory
11. Löschung aller Snapshots via Snapshot-Manager. Etwas überrascht, das unglaublich schnell abgeschlossen. Aber waren nicht mehr gelistet im Manager.
12. Vergrösserung der Festplatte auf 100GB --> meldung das Datastore voll ist (Erstes Grübeln), wurde automatisch auf 80GB eingestellt. Aber nichts weiter dabei Gedacht.
13. VM ging wie gewünscht an, also wollte ich eine Kopie ziehen. VM aus und DS-Browser geöffnet. Feststellung das Snapshots noch effektiv auf der Platte vorhanden sind. Grübeln.
14. Hier meine Verwunderung gepostet.

Noch was dazu: Keinerlei Veränderungen an Config-Files vorgenommen.

Du hast also gleich PM, darfst (fast) jederzeit anrufen.

Grüsse und so

[continuum]

Komisch, komisch ....

so wie es aussieht hast du nicht einen einzigen snapshot - sondern 3 normale Platten.
Der Inhalt der SV-SBS2008.vmdk ist dir ja bekannt - das ist deine problem VM wie sie derzeit ist.

Die anderen beiden weurde ich mir mal jeweils in eine eigene VM einbauen und diese mit Knoppix oder sowas booten - dann kannst du dir mal angucken was da denn wohl drauf ist ???

[UrsDerBär]

Nunja, was seltsam ist, er greift ja nicht auf die Datei ohne die Nummerierung zu, sondern auf die mit der 0001. Seltsam oder? Die hat nun auch 80GB *kopfkratz*

Anbei die Logs... Key wie gehabt.
http://ifile.it/lct9b0j/SV-SBS-Back.rar

Mit Linux kenne ich mich nicht so wirklich gut aus. Kann ich sie auch einfach sonst starten? Also eine Vmx welche auf den Pseudo-Snapshot verweist?

Kann ich das via WS 6.5 tun und gleichzeitig RAM der VM reduzieren? VM ist 2008er Server Version.

Sind in den Logs/vmdk-Textfiles usw. eigentlich daten welche 'geheim' sind oder kann man die 'einfach so' veröffentlichen?

[continuum]

Du kannst auch jede andere VM nehmen und die "pseudo-snapshots" da einbinden.
Mit Workstation natuerlich auch.

Knoppix war nur als Beispile genannt weil fast jeder eine rumliegen hat ...Hmm - steht in den logs was brisantes drin ?

in ESX logs steht nicht soviel drin wie in WS-logs - cih wuesste keine Grund da besonders vorsichtig zu sein.

Hmm - in den logs werden unterschiedliche vmdks als scsi0:0 verwendet - wer hat das umgestellt ? oder passiert da was ganz komisches ?

Also da hilft nur eins - sich alle einzeln angucken - vielleicht steht sogar ueberall dasselbe drin ...

also das ist mir beim besten Willen zu hoch

[UrsDerBär]

Salute,

Wie gesagt, umgestellt habe ich in den Config-Files gar nichts und ausser mir hat auch keiner Zugriff darauf. Also gehe ich mal davon aus, dass der ESX das selbst gemacht hat.

Also ich habs mal folgendermassen gemacht für alle Platten:
1. Config-Files in einen neuen Ordner kopiert
2. Festplatte in den Ordner kopiert und in VMX Festplatte geändert.
3. VM gestartet

Sämtliche angeblichen Snapshots sind anscheinend vollwertige Festplatten mit allen Inhalten. Jede kommt mit dem OS zumindest korrekt hoch.

Hab aber etwas Mühe einzelne Dienste zu überprüfen, weil das ganze unglaublich langsam ist, wohl viel zu wenig RAM für den SBS.

Wenn ich die Modifikationsdatümer so anschaue, denke ich, dass er durch die Entfernung aus dem Inventory tatsächlich die Snapshots in Festplatten umgewandelt hat.

Fragt sich jetzt wie ich vorgehen sollte. VM so weiterverwenden und 'überflüssige' Files löschen oder Windows aus der VM heraus sichern und in eine jungfräuliche hinein wiederherstellen.

Was meinst du, greift er aufgrund der Config-Files noch irgendwie auf die anderen Festplatten zu?

[e-e-e]

Hallo,

Du hast doch innerhalb der VM die "Modifikationdatümer" überprüft, oder?
Versuch doch mal, die 3 "neuen" VMs mit den einzelnen Platten (*.vmdk) in eine Testumgebung zu hängen und ein compare zu starten, damit kannst Du dann die genauen Unterschiede feststellen und Du kannst das korrekte Laufen der einzelnen Dienste in den VMs kontrollieren. Wenn die VMs wegen der RAM-Zuteilung zu langsam sind, ändere doch temporär einfach die *.vmx.

[continuum]

Ich wuerde erstmal denken dass die VM die die 000001.vmdk verwendet am aktuellsten ist - die wurde jedenfalls in der letzten Zeit am haeufigsten verwendet.

Die anderen beiden wuerde ich mir noch eine Weile verwahren - und dann in einer Woche oder so wegwerfen - wenn die andere ok laeuft

[UrsDerBär]

Salut ihr beiden,

Also die Disks funktionieren definitiv alle separat und sind auch nicht vom gleichen Stand. Ist das nicht interessant?

Auf meinem PC mittels WS 6.5 brauchten die anderen beiden jedoch etwas Gedenkzeit + einen Neustart. Windows hat irgendwas geändert, gemeckert mit einer etwas seltsam simplen MsgBox welche ich in dieser Art noch nie gesehen habe und verlangte nen neustart. Leider zu schnell geklickt, sonst hätte ich nen Screenshot gemacht. Ging allerdings jeweils recht lange bis zu dieser Msg (15-30min). Vor diesem Neustart hatte ich keinerlei Zugriff auf irgendwelche Verwaltungsdienste, gab immer TimeOuts. Seltsame Sache. Nach dem Neustart lief alles problemlos.

Werde mal die Disks welche zuviel sind auf der SAN verchieben, nochmals testen und dann von der SAN löschen.

Sollte ich, um in Zukunft probleme mit Snapshots zu vermeiden, die 0001er in die 'normale' umbenennen + vmdk anpassen? Oder ist das egal?

[continuum]

Das wollte ich dir eh noch empfehlen - benenn die vmdk um - so dass sie wieder den normalen Konventionen folgt.

also
blabla-000001.vmdk in blabla.vmdk
blabla-000001-flat.vmdk in blabla-flat.vmdk

[UrsDerBär]

Für jene die auch mal was schrauben müssen:
Nicht vergessen
- innerhalb der blabal-00001.vmdk den pfad von blabla-00001-flat.vmdk blabla-flat.vmddk
- innerhalb der vmx VMX den Pfad von blabla-00001.vmdk auf die neue blabla.vmdk
zu ändern.

[Dayworker]

Solche Blabla_mit_Nummern entstehen auch, wenn es schon eine VMDK gleichen Namens im VM-Verzeichnis gibt. Aber dann sollte eigentlich eine entsprechende Mitteilung seitens VMware kommen...

[continuum]

Aber dann sollte eigentlich eine entsprechende Mitteilung seitens VMware kommen...

iweso ?

VMware verwendet die naechste freie Nummer fuer den naechsten snapshot.
Deswegen sind Ketten wie

basedisk.vmdk - 000009.vmdk - 000005.vmdk - 000002.vmdk moeglich.
Der naechste snapshot hiesse dann 000001.vmdk

[Dayworker]

Da habe ich mich wohl etwas mißverständlich ausgedrückt.
Wenn du in ein bestehendes VM-Verzeichnis mit VMDK eine neue VMDK gleichen Namens anlegen willst, zählt VMware den neuen Datenträger um eins hoch und legt ihn auch im gleichen Verzeichnis an.

Oder ist ESX da anders?

[continuum]

Nein - das macht ESX genauso - der fragt noch nicht einmal nach einem Wunsch-namen wie es die anderen Platformen machen.
Motto: stumpf ist Trumpf