flat File sichtbar im Datastore Browser

[parkesel]

Hallo Leute,

Kenn jemand zufällig diese Situation?

Habe 3 Esx Server welche sich einen Lefthand Cluster teilen, fast jeder Server hat einen dedizierte LUN, als Backup wird VEEam verwendet.

das Vmfs wurde geupdatet da vorher auf den ESXen 4.0 drauf war, aber ich weis nicht ob dieses problem seit den update besteht....

Komisch ist:

- browse ich im Datastore browser sieht man 2 vmdks, server.vmdk und server-flat.vmdk, normalerweise sieht man das flat file nur unter ssh.
- macht man einen snapshot passt es unter datastore browser also er erzeug nicht ein 0001.vmdk sondern es gibt nur mehr einen server.vmdk, unter ssh listet er die 0001,vmdk und das 0001.delta..vmdk auf.(sogar das flat file sieht man somit nicht mehr unter datastore browser)
- ich kann das vmx file im laufwenden betrieb nicht mehr downloaden, das selbe gilt für ein cat server.vmx

Sonst funktioniert alles, nur der Kunde ist etwas irritiert.... kennt jemand zufällig dieses problem?

wenn man sich direkt mit den Hosts verbindet gibt es das selbe Problem, reboot eines Hosts ergab keine änderung....

Esx Version 5.5U1 Vcenter 5.5 glaub ich.

Danke für eure Hilfe

[irix]

Also normal ist das Verhalten nicht. Wissen muss man aber das wenn die VM laeuft nur der ausfuehrende ESXi Host Zugriff auf die *.vmx hat. Du must also sicherstellen das du per SSH auf den richtigen Host gehst.

Ich persoenlich bin nicht so ein grosser Fan von VMFS welches man aktualisiert hat von 3.x auf 5.x wegen der vielzahl der Aenderungen. Sofern moeglich wuerde ich neue frische Datastores anlegen und die VMs migrieren.

Wenn der DS Browser dauerhaft 2 Einzeldateien anstelle einer vDisk anzeigt dann ist etwas auch dauerhaft kaputt und ein Wiedereinschalten der VM wird nicht gehen.
So eine wechselnde Anzeige ist mir nicht bekannt.

Was sein kann das von vorherigen Migrationen Dateien rumliegen von denen man meint das sie Aktuell sind. Des weiteren gibts von Helper Snapshots welcher oftmals 16MB Gross sind welche liegen bleiben.

Mit dem Support fuer Quiscing des FS/Apps in Windows VMs hat sich was am Snapshotverhalten geaendert. Auch der Ablageort von Snaps hat sich geaendert wobei man das nur merkt wenn die vDisks einer VM sich auf mehrere DS verteilen.

Nicht immer schafft es das Backupprogramm den Snap wieder zuloeschen.

Gruss
Joerg

[parkesel]

Hallo irix,

danke für deine schnelle Antwort,

komische Sache, der Admin hat bei einer "unwichtigen" VM versucht diese auszuschalten, dann verschwindet das flat file, sobald er sie wieder einschaltet taucht es wieder auf....

naja habe ihn gesagt er soll versuchen neue vmdks zu erstellen mit vmfs 5 und dann die vm auf diese rüber zu verschieben "storage Migration"

anderes fällt mir nichts mehr ein

Danke und schönen Tag

[Dayworker]

So ein Flatfile kann auch entstehen, wenn man beim Anlegen einer VM das Flat bereits als Beschreibung mitführt. Wie der DS-Browser auf sowas reagiert, hab ich mir nicht angesehen. Möglich wäre jedoch, daß er dann das Flatfile versteckt.

Ich würde, wie von "irix" vorgeschlagen, vorgehen und das VMFS neu aufbauen. Ansonsten schleppt man einige Altlasten von VMFS3 mit und wundert sich später über merkwürdige Probleme.

[continuum]

Das beschriebene Verhalten des Datastorebrowsers ist nicht normal.

Zum Verständnis ...
Flat.vmdks und delta.vmdks sind binäre Dateien ohne vmdk-descriptor.
name.vmdk sind textdateien. In der Zeile "extent description" wird der Pfad zur zugehörigen Binärdatei angezeigt.

Normalfall:
angezeigt werden beispiel.vmdk
real vorhanden:
beispiel.vmdk
beispiel.vmdk + beispiel-flat.vmdk oder
beispiel.vmdk + beispiel-delta.vmdk

angezeigt werden: beispiel.vmdk und beispiel-flat.vmdk
real vorhanden:
beispiel.vmdk + beispiel-flat.vmdk oder
beispiel.vmdk + beispiel-flat.vmdk + ?-flat.vmdk (flat auf die in beispiel.vmdk verwiesen wird)

Das normale Anzeigeverhalten des Datastorebrowsers kann man getrost als völlig daneben bezeichnen. Ein Filemanager sollte normalerweise völlig eindeutig anzeigen !!!
Ein Filemanager sollte meiner Meinung nach anzeigen was real vorhanden ist ohne den Inhalt der Dateien selber zu deuten.

Der Datastorebrowser geht anders vor - bevor er irgendetwas anzeigt werden erstmal alle vmdk-descriptoren gedeutet. Erst danach wird dann entsprechend angezeigt.

- einzelne vmdk:
das bedeutet im Normallfall dass die Binärdatei auf die im Descriptor verwiesen wird entwerder nicht vorhanden oder korrekt vorhanden ist
- flat.vmdk:
es wird eine Binärdatei gefunden für die es im selben Verzeichnis keinen Descriptor gibt
- flat.vmdk + vmdk gleichen Namens:
es handelt sich entweder um völlig unabhängige Dateien oder es liegt ein syntaxfehler in der descriptor.vmdk vor

Datastorebrowser zeigt genau genommen also nur defekte vmdks korrekt an !!!
Nimmt man jetzt noch den Fall dazu, das auch handeditierte vmdks angezeigt werden sollen - dann ist das Ergebnis eine Katastophe:
Für die Administration bedeutet dass: sobald der Datastorebrowser flat.vmdks oder delta.vmdks anzeigt muss davon ausgegangen werden, dass entweder descriptorfiles defekt sind oder fehlen - oder dass unsachgemässe manuelle Eingriffe erfolgt sind.

Aus der Praxis lernt man schnell dass man fehlerhafte Umbenennaktionen unbedingt einkalkulieren muss - tut man das nicht und löscht darufhin scheinbar unbenutzte Dateien hat man massive Probleme.

Im konkreten Fall würde ich dringend empfehlen auf WinSCP zu wechseln - WinSCP zeigt korrekt an und der embedded Texteditor ist in der Lage descriptorfiles anzuzeigen und korrekt zu editieren.

Was ich normalerweise nicht beobachte ist die unterschiedliche Darstellung des Datastorebrowsers bei aktiver Nutzung.
Ich kennen bisher nur den Fall das vmdks unbenutzbar sind sobald statt einer vmdk die flat.vmdk zusätzlich angezeigt wird.

[ohhmille]

Moin in die Runde

Ich habe dasselbe Problem wie oben beschrieben, dass in einer meiner VCSA 6 Umgebungen im datastore browser die FLAT-Files angezeigt werden.
Allerdings nicht für EINE Maschine, sondern für ALLE! Dazu kommt noch, dass es auf zwei verschiedenen datastores auftritt.

Die Descriptor - files werden mit der "echten" Größe von 0,68 KB angegeben. Ich habe quasi die gleiche Anzeige wie über die Console.

VCSA-Version: 6.0 U3a - build 518 3552
HOST-Version: 5.5.0 U3b - build 324 8547
datastore: VMFS 5.58 / Block Size 1 MB

Was kann ich tun? Testweise mal eine VM auf den local datastore verschieben?

Danke und grüße
Mille

[Dayworker]

Häng dich doch mal per SSH auf das Storage und schau selbst nach, was wirklich da ist. Solche Flat-Files können auch sichtbar werden, wenn jmd ungeschickt beim umbenennen der VMDK ist.

[ohhmille]

Grundsätzlich kein schlechter Gedanke. Allerdings bin ich der einizige bei uns, der das machen könnte / würde. Allerdings gab es dazu auch keinen Anlass.
Zumal es die Hälfte der VMs betrifft, nämlich 9 von 18 und auf zwei verschiedenen datastores.

Wenn ich einen Snapshot mache, werden alle Dateien korrekt angezeigt. VMDK in voller Größe. Auch wenn ich eine VMs herunterfahre wird die "FLAT-Datei" nicht mehr angezeigt...

[Dayworker]

Unabhängig davon ob du der einzigste wärest, der sowas machen kann/würde, häng dich Bitte per SSH bzw WinSCP drauf und poste den Storageinhalt inklu freien Platz. Alles andere macht wirklich keinen Sinn, der DS-Browser war und ist weiterhin eine unglaubliche Krücke.

[UrsDerBär]

Alles andere macht wirklich keinen Sinn, der DS-Browser war und ist weiterhin eine unglaubliche Krücke.

Naja, man kann ihn schon nehmen. Aber ausschliesslich zum kopieren von Ordnern, nicht Dateien. Höchstens mal ne VMX hochladen. Alles andere sollte man vermeiden.

[Dayworker]

Wenn ich damit gefahrlos nur eine VMX sprich ASCII-Datei hochladen kann, würde ich mir den DS-Browser gleich komplett ersparen und generell auf etwas zuverlässigeres ausweichen. Das erspart dann im Ernstfall, durch den seit Jahren bemängelten Interpretationsblödsinn des DS-Browser bedingte, weitere Fehler.

[UrsDerBär]

Wenn ich damit gefahrlos nur eine VMX sprich ASCII-Datei hochladen kann, würde ich mir den DS-Browser gleich komplett ersparen und generell auf etwas zuverlässigeres ausweichen. Das erspart dann im Ernstfall, durch den seit Jahren bemängelten Interpretationsblödsinn des DS-Browser bedingte, weitere Fehler.

Im Grunde schon korrekt, aber Kopieraktionen fand ich bis jetzt eigentlich fast entspannter mit dem Browser als mit WinSCP. Schlicht weil mir WinSCP schon öfter in ein Time-Out ging und man anschliessend keinen Plan mehr hatte wie weit er damit eigentlich ist. Jobs abbrechen kann man theoretisch, klappt aber meistens nicht. Nachher muss man sich mit der Konsole herumärgern um alles herauszufinden was gerade noch abgeht. Macht man das nicht täglich, ist das extrem mühsam wie ich finde.
Der DS-Browser dagegen stürtzt extrem selten ab. Es lässt sich zwar auch nichts richtig abbrechen, dafür weiss man immer ob er noch am werkeln ist. Von Daher: Ganze Ordner hoch- /runterkopieren oder nur die VMX kopieren und man hat auch mit dem DS-Browser keinen Ärger. Aber schon klar, ein Armutszeugnis ist er schon