[SOLVED] Bluescreen und anschließend Partitionstabelle Schrott - Windows Server

[HBO]

Guten Morgen,

aktuell ist ein nicht aktuelles PVE 5.3.6 im Einsatz, Update steht auf der ToDo.
Ich hatte nun ein sehr seltsames Phänomen: Im Abstand von 2-3 Stunden hatten 3 Windows Server VMs (2012, 2016 und 2019) einen Bluescreen (Memory Allocated) und booteten anschließend nicht mehr. Überprüfung ergab eine total zerschossene und nicht wiederherstellbare Partitionstabelle. NTFS MTF live und backup korrupt (Datenrettung mit diversen Tools hat geklappt). Der Crash war leider jeweils vor den nächtlichen Backups.

Ist sowas schonmal jemanden passiert? An was könnte dies liegen? Auf dem System liegen weitere Windows Server VMs in verschiedenen Versionen die absolut keine Probleme machen. Diese habe ich aber vorsichtshalber von der Hardware weg migriert.

Hardware ist ein Supermicro Dual Xeon System mit Samsung Enterprise SSD an einem Raid 10 (mit Controller und BBU) und LVM Thin Pool. Fehlermeldungen weder per IPMI noch in der Syslog vorhanden.

Viele Grüße
HBO

 

[Alwin]

Das hört sich nach einem Problem in der VM an. Windows up-to-date? VirtIO Treiber aktualisiert?

 

[HBO]

Die VMs hatten jeweils aktuelle Patch Stände und wurden auch durch die Windows Updates generell immer ohne Probleme neu gestartet.
Frisch dazu gekommen ist auch eine Windows 10 VM (auch aktueller Patch stand) die ich per live Migration weg geschoben habe. Ich hatte anfangs vermutet die Hardware hätte Probleme. Nach einem Adobe Reader Update musste ich diese neu starten.
Der Bootvorgang dauerte extrem lange, abschließend ein Bluescreen mit Critical Device Error. Anschließende Untersuchung der Disks ergab kein gefundenes OS und auch die typischen "bootrec" Befehle halfen hier nicht. Exakt gleiches Verhalten bei den anderen VMs.

Die VirtIO Treiber waren allerdings nicht die aktuellsten, glaube Version 149 dürfte das gewesen sein.

Irritierend finde ich nur das dieses Problem nach und nach im Verlauf von Stunden alle VMs einer Node betrifft. Windows VMs auf 3 anderen Nodes haben dieses Verhalten bisher nicht.

 

[Alwin]

Irritierend finde ich nur das dieses Problem nach und nach im Verlauf von Stunden alle VMs einer Node betrifft.

Auf dem System liegen weitere Windows Server VMs in verschiedenen Versionen die absolut keine Probleme machen.

Diese Aussagen sind gegenläufig.
Was trifft jetzt zu? Alle VMs oder nur bestimmte VMs sterben?

 

[HBO]

Bisher betroffen waren alle VMs von Node1. Alle VMs die noch nicht gecrasht waren habe ich per live Migration auf Node2 geschoben. Allerdings scheinbar mit der Problematik, denn ein Crash dieser VMs fand nachträglich auch statt.
Leider habe ich nun bei einer Überprüfung einer weiteren VM die von vorn herrein auf Node2 lag auch das Problem. Die VM reagiert was den Windows Desktop angeht so gut wie gar nicht mehr, Desktop Symbole sind zerstört usw.

Mir gehen die Ideen aus woher sowas kommt und vor allem wie ich es verhindern und vielleicht doch beheben könnte.

*edit*
Ich habe jetzt mal ein simples "fdisk" ausgeführt auf der Node (LVM Thin Pool):

Funktionierende VM:

Disk /dev/mapper/pve-vm--106--disk--0: 300 GiB, 322122547200 bytes, 629145600 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 262144 bytes / 262144 bytes

Disklabel type: dos

Disk identifier: 0x9d6c2665


Device                                 Boot   Start       End   Sectors   Size Id Type

/dev/mapper/pve-vm--106--disk--0-part1 *       2048   1126399   1124352   549M  7 HPFS/NTFS/exFAT

/dev/mapper/pve-vm--106--disk--0-part2      1126400 629141503 628015104 299.5G  7 HPFS/NTFS/exFAT

Kaputte VM:

Disk /dev/mapper/pve-vm--201--disk--0: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes

Ja tatsächlich, keine Partitionsinformationen.

 

[Alwin]

Leider habe ich nun bei einer Überprüfung einer weiteren VM die von vorn herrein auf Node2 lag auch das Problem. Die VM reagiert was den Windows Desktop angeht so gut wie gar nicht mehr, Desktop Symbole sind zerstört usw.

Sind die Nodes gleich aufgebaut?
Wie ist die Auslastung der Nodes?

 

[HBO]

Identische Hardware, Supermicro Sys 1029U TR4, 2x Xeon Gold 6130, 256 GB RAM, Supermicro 3108 RAID Controller, 8x Samsung Enterprise SSD im RAID 10 und LVM Thin Pool. 0 IO Delay, 10-15% CPU Last und eine load von 2.

 

[Alwin]

Wie ist die Performance des Storage?
https://pve.proxmox.com/wiki/Benchmarking_Storage

Ist etwas im Syslog zu finden?

 

[HBO]

Hier die fio Ergebnisse:

Spoiler: Read

fio --ioengine=libaio --direct=1 --sync=1 --rw=read --bs=4K --numjobs=1 --iodepth=1 --runtime=60 --time_based --name seq_read --filename=/dev/sda
seq_read: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [128.2MB/0KB/0KB /s] [32.9K/0/0 iops] [eta 00m:00s]
seq_read: (groupid=0, jobs=1): err= 0: pid=33145: Thu Oct  1 09:35:39 2020
  read : io=7701.7MB, bw=131438KB/s, iops=32859, runt= 60001msec
    slat (usec): min=3, max=619, avg= 3.66, stdev= 0.81
    clat (usec): min=1, max=1550, avg=26.22, stdev= 5.51
     lat (usec): min=27, max=1554, avg=29.88, stdev= 5.58
    clat percentiles (usec):
     |  1.00th=[   24],  5.00th=[   25], 10.00th=[   25], 20.00th=[   25],
     | 30.00th=[   25], 40.00th=[   25], 50.00th=[   25], 60.00th=[   26],
     | 70.00th=[   26], 80.00th=[   26], 90.00th=[   27], 95.00th=[   29],
     | 99.00th=[   54], 99.50th=[   54], 99.90th=[   58], 99.95th=[   65],
     | 99.99th=[  104]
    lat (usec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=98.26%
    lat (usec) : 100=1.72%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
    lat (msec) : 2=0.01%
  cpu          : usr=5.53%, sys=22.49%, ctx=1971641, majf=0, minf=32
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=1971607/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=7701.7MB, aggrb=131438KB/s, minb=131438KB/s, maxb=131438KB/s, mint=60001msec, maxt=60001msec

Disk stats (read/write):
  sda: ios=1975918/3194, merge=1384/1223, ticks=48892/904, in_queue=49552, util=78.66%

Spoiler: Read 4k

fio --ioengine=libaio --direct=1 --sync=1 --rw=read --bs=1M --numjobs=1 --iodepth=1 --runtime=60 --time_based --name seq_read --filename=/dev/sda
seq_read: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=1
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [1539MB/0KB/0KB /s] [1539/0/0 iops] [eta 00m:00s]
seq_read: (groupid=0, jobs=1): err= 0: pid=33395: Thu Oct  1 09:37:19 2020
  read : io=97902MB, bw=1631.7MB/s, iops=1631, runt= 60001msec
    slat (usec): min=37, max=496, avg=45.64, stdev=15.83
    clat (usec): min=180, max=7555, avg=566.28, stdev=125.33
     lat (usec): min=230, max=7597, avg=611.92, stdev=126.21
    clat percentiles (usec):
     |  1.00th=[  205],  5.00th=[  510], 10.00th=[  510], 20.00th=[  516],
     | 30.00th=[  516], 40.00th=[  516], 50.00th=[  524], 60.00th=[  532],
     | 70.00th=[  564], 80.00th=[  620], 90.00th=[  692], 95.00th=[  764],
     | 99.00th=[  940], 99.50th=[ 1032], 99.90th=[ 1400], 99.95th=[ 1752],
     | 99.99th=[ 4960]
    lat (usec) : 250=1.02%, 500=0.14%, 750=92.94%, 1000=5.30%
    lat (msec) : 2=0.57%, 4=0.02%, 10=0.02%
  cpu          : usr=0.33%, sys=8.73%, ctx=97923, majf=0, minf=269
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=97902/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=97902MB, aggrb=1631.7MB/s, minb=1631.7MB/s, maxb=1631.7MB/s, mint=60001msec, maxt=60001msec

Disk stats (read/write):
  sda: ios=391471/4103, merge=1/1540, ticks=207512/1252, in_queue=207604, util=94.63%

Die Syslog ist ohne Fehler, ich habe mir die letzten 48 Stunden vor Ausfall angeschaut.

Besteht eine Möglichkeit an die Partitionsinformationen wieder ran zu kommen? Per Live CD und Testdisk sind diese in der VM ersichtlich. Es fehlen aber alle Informationen zu Typ, MBR und die MTF Tabellen des NTFS Dateisystems. Selbst die Backup MTF ist nicht vorhanden.

 

[Alwin]

Besteht eine Möglichkeit an die Partitionsinformationen wieder ran zu kommen? Per Live CD und Testdisk sind diese in der VM ersichtlich. Es fehlen aber alle Informationen zu Typ, MBR und die MTF Tabellen des NTFS Dateisystems. Selbst die Backup MTF ist nicht vorhanden.

Windows Repair, denk ich mal. Aber das zeigt ja schon, dass etwas am Storage oder in Kombination nicht stimmt.

Wenn das Problem durch die Bank mit der Hardware auftritt, ist es wohl am besten, wenn eine Node vom Cluster separiert wird. Dann lässt sich mit der Node leicht testen, ohne das Cluster selbst zu beeinflussen. Auch kann die Node mal mit PVE 6.2 neu installiert werden. Evtl. hat sich damit das Problem dann auch schon erledigt.

Zusätzlich würde sich ein Wechsel auf ein NFS/SMB Share für die VMs anbieten. Da lässt sich dann leicht sehen, ob es direkt mit dem Storage zu tun hat.

 

[HBO]

Windows Repair scheitert aufgrund der fehlenden MTF leider auch, findet nicht mal eine vorhandene Installation.
Dann bleibt wohl leider nur Desaster Recovery.

Ich bin am Überlegen vom Raid Controller weg zu ZFS zu wechseln. Da ich aber nur 8 Einschübe haben brauche ich bei 8x Samsung PM863a SSDs für die Performance ein Log / Cache?

 

[Alwin]

Ich bin am Überlegen vom Raid Controller weg zu ZFS zu wechseln. Da ich aber nur 8 Einschübe haben brauche ich bei 8x Samsung PM863a SSDs für die Performance ein Log / Cache?

Ein ZIL kann auch im nachhinein installiert werden. Aber es ist ja noch nicht fix, dass es der Controller ist.

 

[HBO]

Werde ich dann alles mal durch testen. Ich installiere nun erstmal Node1 neu und baue auch gleich mal den Cluster neu auf. Sollte es doch weiterhin Probleme geben erstelle ich einen neuen Thread.