Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Datestore nach Update von 6.5 auf 6.7 verloren

Alles zum Thema vSphere 6.7, ESXi 6.7 und vCenter Server.

Moderatoren: irix, Dayworker

Member
Beiträge: 7
Registriert: 21.02.2018, 07:52

Datestore nach Update von 6.5 auf 6.7 verloren

Beitragvon itksystemhaus » 12.09.2019, 06:53

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

King of the Hill
Beiträge: 12942
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Re: Datestore nach Update von 6.5 auf 6.7 verloren

Beitragvon irix » 12.09.2019, 08:17

Du solltest Kontakt mit dem Ulli Hankel aka Continium aufnehmen. Er ist hier im Forum und im VMTN der Datenwiederherstellungs Profi. Seine Telefonummer steht in seiner Signatur bzw. auch auf http://www.sanbarrow.com/sickbay.html

Gruss
Joerg

Guru
Beiträge: 2731
Registriert: 23.02.2012, 12:26

Re: Datestore nach Update von 6.5 auf 6.7 verloren

Beitragvon ~thc » 12.09.2019, 08:35

Auch wenn du das nicht hören willst: Warum dieses Update? Gibt es eine Funktionalität, die 6.5 nicht bietet und die ihr dringend benötigt? 6.5 und 6.7 haben auch den gleichen Support-Zeitraum.

Die VMFS-Partition hat immer die Nummer 3. Nach der 6.5er Erstinstallation sollte der Datastore als "datastore1" mit dem "Rest" der Platte immer automatisch vorhanden sein - den muss man also nicht anlegen.

Du kannst auf der SSH-Shell nachschauen, ob der Datastore als Snapshot detektiert wird:

Code: Alles auswählen

esxcli storage vmfs snapshot list


Und du kannst schauen, ob das Volume erkannt wird:

Code: Alles auswählen

esxcfg-volume -l

Profi
Beiträge: 875
Registriert: 18.03.2005, 14:05
Wohnort: Ludwigshafen

Re: Datestore nach Update von 6.5 auf 6.7 verloren

Beitragvon Martin » 12.09.2019, 09:20

Noch eine Ergänzungsfrage:
Wie hast Du das Upgrade durchgeführt? Auf welchem Weg / mit welchem Befehl?

Member
Beiträge: 7
Registriert: 21.02.2018, 07:52

Re: Datestore nach Update von 6.5 auf 6.7 verloren

Beitragvon itksystemhaus » 12.09.2019, 12:13

Hallo,

vielen Dank schon mal für die Antworten. Ich habe die 6.7 von CD gebootet und dort die Update-Option gewählt. Das lief ganz normal durch.

Das Update habe ich installiert, weil ich unsere alten 2012er-Server durch 2019 ersetzt habe und mir dachte, dass ich vielleicht neuere VM-Ware Tools bekomme und in der Betriebssystemauswahl dann auch den 2019er Server angeboten bekomme.

Die beiden Befehle habe ich ausgeführt, das Ergebnis ist folgendes.

[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)


Der Volume Name wurde richtig erkannt mit "system-volume". Die Meldung, dass der Datastore mountable ist, hört sich gut an. Ist nur die Frage, wie?

Gruss
Ralph

Member
Beiträge: 7
Registriert: 21.02.2018, 07:52

Re: Datestore nach Update von 6.5 auf 6.7 verloren

Beitragvon itksystemhaus » 12.09.2019, 12:44

Hallo nochmal,

ich habe gerade 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

lässt mich hoffen, dass das nun dauerhaft gemountet bleibt. Wäre noch die Ursache interessant, aber Hauptsache es geht wieder, bin erst mal happy und sichere die VM erst mal.

Vielen Dank für die schnelle Hilfe.

Ralph

King of the Hill
Beiträge: 12942
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Re: Datestore nach Update von 6.5 auf 6.7 verloren

Beitragvon irix » 12.09.2019, 13:12

Ja mit "-M" wird das Volume wieder dauerhaft gemountet. Die Alternative sonst waere gewesen eine neue Signatur zu schreiben.

Dieses Verhalten trifft nur auf wenn der Host ein Volume sieht was aber nun von "aussen" anders (Target/Controller/Lun) an ihn praesentiert wird und er beim hinein gucken eine ihm bereits Signatur vorfindet. Dann denkt er das er eine "Kopie" (Snapshot) vorliegen hat und wartet auf den Admin.

Wenn du den Erstelle Datastore Workflow im WebClient einen Schritt weiter geklickt haettest dann waere das mit der Frage nach der Signatur hervorgetreten.

Gruss
Joerg


Zurück zu „vSphere 6.7“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste