VMware Global Community
rlieske
Contributor
Contributor

Datestore nach Update von 6.5 auf 6.7 verloren

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

Reply
0 Kudos
1 Reply
rlieske
Contributor
Contributor

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.

Reply
0 Kudos