1 Reply Latest reply on Sep 12, 2019 4:41 AM by rlieske

    Datestore nach Update von 6.5 auf 6.7 verloren

    rlieske Lurker

      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

        • 1. Re: Datestore nach Update von 6.5 auf 6.7 verloren
          rlieske Lurker

          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.