VMware vCenter Appliance 6.0 crashed

[DocData 85]

Ich kenne den Thread und ich kenn deinen Beitrag damals dazu. Dazu du immer etwa zickig bist, sofern deine Lösungsansätze nicht verfolgt werden, weiß ich. Deswegen wunderte mich der Kommentar nicht...

[zahni 587]

Den Beitrag kannst Du jetzt locker auf Dich anwenden. So, nun zurück zum Thema:

 

Google meint z.B. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2081464

 

Edit oder: http://blog.grogscave.net/2016/06/recovering-from-vcenter-appliance-disk.html

bearbeitet 25. Juni 2016 von zahni

[DocData 85]

Passt aber nicht. Wie ich bereits zwei Mal erwähnte: Die vSphere Appliance verwendet, und das sieht man auch im Screenshot, einen LVM. Der KB Artikel bezieht sich darauf, dass das Root FS (also /) nicht gemountet werden kann. Dieser Artikel passt nicht.

[zahni 587]

Dann eben der 2. Link.

[DocData 85]

... den du nach meinem Beitrag eingefügt hast. Aber das sind eh die besten Troubleshooting-Tipps... Fehlermeldungen bei Google eintippern und Links posten.

[zahni 587]

... den du nach meinem Beitrag eingefügt hast.

 Weil ich vor Deinem Beitrag danach gesucht habe. Auch Googeln kostet Zeit.

Wen das Problem hätte, würde ich übrigens ein Ticket bei VMWare ziehen. Den Support kauft man ja mit. Da bin ich ganz ohne Google drauf gekommen...

[magheinz 111]

srvvsphereapp01:~ # df -h
Filesystem                            Size  Used Avail Use% Mounted on
/dev/sda3                              11G  4.5G  5.7G  45% /
udev                                  7.9G  164K  7.9G   1% /dev
tmpfs                                 7.9G   40K  7.9G   1% /dev/shm
/dev/sda1                             128M   38M   84M  31% /boot
/dev/mapper/core_vg-core               50G  182M   47G   1% /storage/core
/dev/mapper/log_vg-log                9.9G  6.7G  2.8G  72% /storage/log
/dev/mapper/db_vg-db                  9.9G  282M  9.1G   3% /storage/db
/dev/mapper/dblog_vg-dblog            5.0G  219M  4.5G   5% /storage/dblog
/dev/mapper/seat_vg-seat               25G  1.1G   23G   5% /storage/seat
/dev/mapper/netdump_vg-netdump       1001M   18M  932M   2% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy  9.9G  151M  9.2G   2% /storage/autodeploy
/dev/mapper/invsvc_vg-invsvc          9.9G  487M  8.9G   6% /storage/invsvc

Es gibt also gemountete Partitionen als auch LVs.

sda3 ist also tatsächlich gemountet, und das an einer nicht ganz unwichtigen Stelle...

sda2 ist übrigens swap. Auch ohne LVM...

[DocData 85]

Wen das Problem hätte, würde ich übrigens ein Ticket bei VMWare ziehen. Den Support kauft man ja mit.

Joar, die Jungs in Cork bekommen das sicher schnell in einer WebEx hin.

 

 

Es gibt also gemountete Partitionen als auch LVs.

sda3 ist also tatsächlich gemountet, und das an einer nicht ganz unwichtigen Stelle...

sda2 ist übrigens swap. Auch ohne LVM...

Jap, das es /dev/sda3 gibt, habe ich nicht angezweifelt. Aber: Das ist nicht das Problem. Ein Filesystem was gemountet wird, hat erstmal kein großes Problem. Das Problem ist /dev/mapper/core_vg-core. Das muss geprüft werden. Insofern ist diese Diskussion irgendwie sinnfrei.

[v-rtc 92]

Hallo zusammen,

 

erst mal ganz ruhig, alle locker bleiben.

 

Da ich beim Maintanence booten nur die /dev/sda3 gesehen hatte, habe ich den Hinweis auf das LVM überlesen. Danke an DocData für die richtige Richtung. Zahni danke für den zweiten Link, der wars! :thumb1:

LVMs sind schon eine ganze Weile her, dass ich es nicht mehr wusste und bei Google schlechter gesucht hatte wie Du zahni. ;)

 

Wie gesagt haben wir nur Basic Support, der Hilft nur Mo-Fr. :(

 

Danke an alle, wieder etwas gelernt. Backup folgt  :D

 

Grüße

 

​Rolf

[magheinz 111]

na dann jetzt halt noch fsck /dev/mapper/core_vg-core und alles wird gut...