Hallo,
ich habe am Wochenende ein Update von 6.5 auf 6.7 durchgeführt. Das Update lief ohne Probleme und Fehlermeldungen durch. Nach dem Neustart des ESXI ist mir aufgefallen, dass eine VM fehlt. Nachdem ich genauer nachgesehen habe, stellte ich fest, dass der ganze Datastore fehlt.
Das System hatte drei Datastores, ein RAID6 Datastore, eine SSD und einen Datastore auf der Systemplatte.
Und letzterer fehlt nun.
fdisk erkennt die Systemplatte und die darauf enthaltenen Partitionen.
[root@vsphere3:~] fdisk -l
***
*** The fdisk command is deprecated: fdisk does not handle GPT partitions. Please use partedUtil
***
Found valid GPT with protective MBR; using GPT
Disk /dev/disks/naa.5000c500b1f9e373: 3907029168 sectors, 3089M
Logical sector size: 512
Disk identifier (GUID): 59be848e-3ec4-4b41-9ce9-81b854b3996b
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Number Start (sector) End (sector) Size Name
1 64 8191 4064K
2 7086080 15472639 4095M
3 15472640 3907029134 1855G
5 8224 520191 249M
6 520224 1032191 249M
7 1032224 1257471 109M
8 1257504 1843199 285M
9 1843200 7086079 2560M
Found valid GPT with protective MBR; using GPT
Da ich jetzt keinen Vergleich zu vorher habe, kann ich nicht sagen, wie es vor dem Update aussah. Aber die Partitionstabelle scheint in Ordnung zu sein und Partition 3 scheint der gesuchte Datastore zu sein. Was mich nur wundert, ist die Reihenfolge. Ursprünglich wurde auf einer leeren Platte die ESXI Version 6.5 installiert und erst, als der Server in Betrieb war, wurde der Datastore angelegt. Wieso der Datastore die Nummer 3 hat finde ich etwas seltsam. Von den Sektoren her ist die Partition jedoch die letzte.
Ich habe weitere Informationen mit partedUtil ausgelesen:
[root@vsphere3:~] partedUtil get /dev/disks/naa.5000c500b1f9e373
243201 255 63 3907029168
1 64 8191 0 128
5 8224 520191 0 0
6 520224 1032191 0 0
7 1032224 1257471 0 0
8 1257504 1843199 0 0
9 1843200 7086079 0 0
2 7086080 15472639 0 0
3 15472640 3907029134 0 0
[root@vsphere3:~] partedUtil getUsableSectors /dev/disks/naa.5000c500b1f9e373
34 3907029134
[root@vsphere3:~] ls /vmfs/devices/disks/
naa.5000c500b1f9e373 vml.0100000000424545445f393134345f344134345f3142303000574453323530
naa.5000c500b1f9e373:1 vml.0100000000424545445f393134345f344134345f3142303000574453323530:1
naa.5000c500b1f9e373:2 vml.02000000005000c500b1f9e373535432303030
naa.5000c500b1f9e373:3 vml.02000000005000c500b1f9e373535432303030:1
naa.5000c500b1f9e373:5 vml.02000000005000c500b1f9e373535432303030:2
naa.5000c500b1f9e373:6 vml.02000000005000c500b1f9e373535432303030:3
naa.5000c500b1f9e373:7 vml.02000000005000c500b1f9e373535432303030:5
naa.5000c500b1f9e373:8 vml.02000000005000c500b1f9e373535432303030:6
naa.5000c500b1f9e373:9 vml.02000000005000c500b1f9e373535432303030:7
naa.600605b00431216016f736407d385305 vml.02000000005000c500b1f9e373535432303030:8
naa.600605b00431216016f736407d385305:1 vml.02000000005000c500b1f9e373535432303030:9
t10.NVMe____WDS250G3X0C2D00SJG0______________________BEED91444A441B00 vml.0200000000600605b00431216016f736407d3853054d5239323630
t10.NVMe____WDS250G3X0C2D00SJG0______________________BEED91444A441B00:1 vml.0200000000600605b00431216016f736407d3853054d5239323630:1
[root@vsphere3:~] partedUtil get "/vmfs/devices/disks/naa.5000c500b1f9e373"
243201 255 63 3907029168
1 64 8191 0 128
5 8224 520191 0 0
6 520224 1032191 0 0
7 1032224 1257471 0 0
8 1257504 1843199 0 0
9 1843200 7086079 0 0
2 7086080 15472639 0 0
3 15472640 3907029134 0 0
Zumindest scheinen alle Partitionen da zu sein und die Partitionstabelle in Ordnung.
Eine Reparatur brachte auch kein neue Erkenntnis. Die gesuchte Partition hat den richtigen Datentyp.
[root@vsphere3:~] partedUtil fixGpt "/vmfs/devices/disks/naa.5000c500b1f9e373"
FixGpt tries to fix any problems detected in GPT table.
Please ensure that you don't run this on any RDM (Raw Device Mapping) disk.
Are you sure you want to continue (Y/N): y
gpt
243201 255 63 3907029168
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 3907029134 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
[root@vsphere3:~] partedUtil getptbl "/vmfs/devices/disks/naa.5000c500b1f9e373"
gpt
243201 255 63 3907029168
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 3907029134 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
[root@vsphere3:~] partedUtil partinfo "/vmfs/devices/disks/naa.5000c500b1f9e373" 3
Partition Number: 3
Start sector: 15472640
End sector: 3907029134
Partition Type GUID: AA31E02A400F11DB9590000C2911D1B8
Partition Unique GUID: D234FD9ACDC242ED92AE8EDB088BD33F
Partition Filesystem Type: vmfs
Partition attributes: 0
Nun weiß ich nicht mehr weiter. Beim scannen erkennt das System den Datastore nicht. Wenn ich einen neuen Datastore anlegen will, wird mir die Systemplatte nicht angezeigt, ist ja auch kein freier Platz mehr darauf.
Was kann ich tun, damit ich wieder Zugriff auf den Datastore bekomme?
Vielen Dank schon mal.
Ralph
Hallo,
das Problem konnte ich inzwischen über ein anderes Forum lösen.
Durch Eingabe der beiden Befehle konnte man sehen, dass der Datastore richtig erkannt wurde, aber eine unbekannte Signatur hatte.
[root@vsphere3:~] esxcli storage vmfs snapshot list
5d6c04bf-0b6dccc6-b7d4-003048cad2ba
Volume Name: system-volume
VMFS UUID: 5d6c04bf-0b6dccc6-b7d4-003048cad2ba
Can mount: true
Reason for un-mountability:
Can resignature: true
Reason for non-resignaturability:
Unresolved Extent Count: 1
[root@vsphere3:~] esxcfg-volume -l
Scanning for VMFS-3/VMFS-5 host activity (512 bytes/HB, 2048 HBs).
VMFS UUID/label: 5d6c04bf-0b6dccc6-b7d4-003048cad2ba/system-volume
Can mount: Yes
Can resignature: Yes
Extent name: naa.5000c500b1f9e373:3 range: 0 - 1900031 (MB)
Ich habe dann nach der Meldung "Unresolved Extent Count:" gesucht und bin dadurch auf die Lösung meines Problems gestoßen.
Mittels
esxcfg-volume -M 5d6c04bf-0b6dccc6-b7d4-003048cad2ba
konnte ich den Datastore wieder mounten.
Die Meldung
Persistently mounting volume 5d6c04bf-0b6dccc6-b7d4-003048cad2ba
bestätigt, dass ich nun wieder dauerhaft darauf zugreifen kann.