dandy-power
Goto Top

Hyper V zerstört bei einem Prüfpunkt den GPT Backup Header einer VM - Windows Server 2019

Hi,

ich bin leider an meine Grenzen gestoßen uns weiß nicht mehr weiter. Vielleicht hat hier jemand einen Tipp für mich.
Vorne weg, die Server laufen eigentlich alle nur ich hab ein kleines Problem mit Prüfpunkten beim Fileserver.

Folgende Ausgangssituation:
Auf einem Blech (Host) läuft ein Windows Server 2019 mit Hyper V
VM1: Windows Server 2019 AD+DC
VM2: Windows Server 2019 inkl. Exchange 2019
VM3: Windows Server 2019 als File + Appserver
VM4: Windows Server 2019 als Backupserver mit Veeam

Seit einigen Tagen habe ich das Problem beim Backup der VMs über Veeam. Wenn ich bei der VM3 also dem Fileserver einzelne Dateien zurücksichern möchte, erhalte ich folgenden Fehler (Bild: GPT-ERROR):
Invalid secondary GPT partition entry array checksum: 3177348369 (calculated: 2736170667) Agent failed to process method {Mount.GenericMount}.

Bei Veeam habe ich ein Ticket gezogen. Es kam dabei raus, dass das Problem an den Prüfpunkten liegt.
Veeam erstellt das Backup in Abhängigkeit der Prüfpunkte und bekommt den Fehler durchgeschleift.

Das Problem ist reproduzierbar, wenn man einen Prüfpunkt in der Hyper V Manager Console bei der VM3 erstellt und diesen wieder löscht. Danach rebootet man die VM und danach hat es die GPT Backup Header Table verbogen und ich bekomme CRC Fehler. Deshalb wird in Veeam auch wie oben beschrieben die Fehlermeldung ausgelöst. Der Server läuft aber ohne erkennbare Probleme trotz der verbogenen Backup GPT Table.

Ich habe nun gdisk benutzt um zu sehen, was falsch ist. Läuft alles, gibt es keine Probleme (Bild: GDISK-OK). Tritt das Problem auf, erhält man folgende Auswertung von gdisk (Bild: GDISK-DAMAGED)

Das Problem mit dem Header kann ich temporär so lösen:
VM herunterfahren und in den VM-Einstellung die Systempartition um 1 GB erweitern. Nach dem Neustart der VM ist das Problem wieder weg. Aber nur so lange, bis wieder ein NEUER Prüfpunkt erstellt wird. Nach einem weiteren Neustart der VM tritt der gleiche Fehler wieder auf. Also wieder VM herunterfahren, Systedisk um 1GB erweitern und nach dem Starten ist das Problem wieder behoben. So lange KEIN Prüfpunkt erstellt wird, kann man die VM so oft herunterfahren/neustarten wie man möchte, das Problem tritt nicht mehr auf. WIrd wieder ein Prüfpunkt erstellt tritt das Problem NACH einem REBOOT wieder auf. So lange man die VM nach dem Prüpunkt nicht neustartet gibt es keine Probleme.

Die Server laufen aber alle ohne Probleme. Das Problem tritt auch nur bei der einen VM Fileserver auf. Host und VMs sind auf dem gleichen aktuellsten Updatepatch.

Kann mir vielleicht jemand sagen, wie ich das Problem fixen kann? Ich habe im Netz leider nicht wirklich etwas darüber gefunden.

Grüße Dandy
gdisk-ok
gdisk-damaged
gpt-error

Content-Key: 560836

Url: https://administrator.de/contentid/560836

Ausgedruckt am: 29.03.2024 um 06:03 Uhr

Mitglied: NordicMike
NordicMike 25.03.2020 um 23:49:58 Uhr
Goto Top
Lass mich raten, du verwendest REFS für die VM?
Mitglied: dandy-power
dandy-power 26.03.2020 um 07:30:58 Uhr
Goto Top
Guten Morgen,

Nein ich benutze NTFS
Mitglied: NordicMike
NordicMike 26.03.2020 um 08:28:11 Uhr
Goto Top
Ich habe mehrere VM's mit Fileserver Rolle und 2019 mit NTFS am laufen. Der Fehler kam nie. Du könntest mal eine neue Test-VM erzeigen und die vorhandene .vhdx einbinden um zu sehen, ob in der Hyper-V Config oder im Image der Wurm drinnen ist.
Mitglied: dandy-power
dandy-power 26.03.2020 um 08:39:31 Uhr
Goto Top
Ich habe ja 4 VMs mit jeweils einem Windows Server 2019 am laufen und die Hyper-V Configs sind identisch bis auf den RAM beim Exchange der ist natürlich größer. Aber das Problem liegt auch nur an der einen VM, die anderen sind nicht davon betroffen.

Aber ich kann ja mal eine neue Test-VM anlegen und dann testen, ob das gleiche Problem dort auch auftritt.
Mitglied: NordicMike
NordicMike 26.03.2020 um 10:38:35 Uhr
Goto Top
Mach mal, in der .xml steht auch mehr drinnen, als das, was Du in der GUI siehst. Wenn es dann immer noch so spakt, ist der Wurm in der .vhdx
Mitglied: dandy-power
dandy-power 26.03.2020 um 14:23:46 Uhr
Goto Top
Habe nun eine neue Vm erstellt und dann die .vhdx eingebunden.
Auch da ist leider das gleiche Problem.

Kann man hier eine Windows Reparaturinstallation laufen lassen, ohne dass meine Daten verloren gehen?

habse sonst keinen anderen Lösungsansatz. Ich würde den Fileserver ungern neu aufsetzen.

Oder kann ich die .vhdx auf eine andere .vhdx kpieren/klonen?
Mitglied: dandy-power
dandy-power 26.03.2020 um 15:49:09 Uhr
Goto Top
Ich habe nun gdisk nochmals laufen lassen und es liegt nicht an den Checkpoints. Das Problem tritt nun auch auf, wenn man den Server herunterfährt/neustartet ohne ein Prüfpunkt auszulösen.

Ich habe mit gdisk die Header reapriert:
C:\Windows\system32>gdisk \\.\physicaldrive0
GPT fdisk (gdisk) version 1.0.5

Warning! Main and backup partition tables differ! Use the 'c' and 'e' options  
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don't match. You should repair the disk!  
Main header: OK
Backup header: OK
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Identified 1 problems!

Command (? for help): p
Disk \\.\physicaldrive0: 199229440 sectors, 95.0 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): BA3E375B-7D66-4985-ADE3-3B229539622B
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 199229406
Partitions will be aligned on 2048-sector boundaries
Total free space is 6297533 sectors (3.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1023999   499.0 MiB   2700  Basic data partition
   2         1024000         1226751   99.0 MiB    EF00  EFI system partition
   3         1226752         1259519   16.0 MiB    0C01  Microsoft reserved ...
   4         1259520       192933887   91.4 GiB    0700  Basic data partition

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to \\.\physicaldrive0.
Disk synchronization succeeded! The computer should now use the new
partition table.
The operation has completed successfully.

Man sieht nach erneutem prüfen, dass es nun keine Fehler mehr gibt.
C:\Windows\system32>gdisk \\.\physicaldrive0
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): q

Lasse ich den Server jetzt neustarten, und überprüfe mit Gdisk wieder das Laufwerk, dann erhalte ich den gleichen Fehler wie oben im ersten Code wieder. Man kann sie dann wieder reparieren und dann wird das auch wieder nach erneutem prüfen ohne Fehler durchlaufen, bis man halt wieder die VM neustartet.


Habe zum testen das gleiche an einigen Clients mit Windows 10 versucht, alle 5 sind ok, bis auf den 6. Client, da ist das gleiche Problem wie hier bei der VM beschrieben. Man kann dann den Header wieder fixen, aber auch da nach einem Reboot erhält man das gleiche Problem wieder.

Scheint also nicht direkt an Hyper-V zu liegen sondern am Windows selber.

Aber an was kann das liegen, dass bei einem Neustart, jedesmal die Header kaputt sind? Der Client und der Server laufen aber ohne Probleme.