Bei 3 verschiedenen Server 3 Linux Gäste zerstört

[Helmut Gruber]

Proxmox VE Versionen 5.1.41, 5.1.41 und 4.4-1

Gäste waren jeweils Linux ( 2x Debian, 1x Proxmox Mailgateway).

Wir haben jetzt beim dritten Server den Effekt, dass eine virtuelle Maschine (jeweils immer Linux) eine Zeit lief, plötzlich Probleme macht, nach dem Aus/Einschalten nicht mehr startfähig ist nach Kontrolle sich herausstellt dass die Gast-Platten leer sind, keine Partitionierung mehr da ist, alle Daten weg.

Auch alle Proxmox-Backups (Snapshot-Backups auf NFS) waren kaputt, nach Rücksicherung nicht bootfähig, Partitionstabelle weg, Daten nicht rettbar (diverse Rescue-CDs durchprobiert).

Von der Hardware haben wir 2 Server mit RAID von Wortmann, und einen Intel NUC mit SSD.

Storage war einmal NFS, einmal local-lvm mit SDD, einmal local-lvm mit SAS-Platten.

Bevor ich den Glauben an alles verliere - hat jemand sowas schon mal gehabt?

 

[dcsapak]

wie sieht die config so einer vm aus?

2 Server mit RAID von Wortmann

was für ein RAID?

 

[Helmut Gruber]

Also der Intel-NUC hat nur eine Samsung EVO SSD drin.
Der eine Wortmann, bei dem die Maschine auf dem RAID zerstört wurde, hat einen Intel RAID RS3DC080 PCIe x8 SAS 8 HD.

Kann ich die config aus einem Backup händisch extrahieren?

 

[dcsapak]

Kann ich die config aus einem Backup händisch extrahieren?

im gui beim backup auf "show configuration" klicken

 

[Helmut Gruber]

Das Linux, das auf einem Wortmann Server lief, hatte die Platte auf NFS (Synology) liegen:
bootdisk: sata0
cores: 2
ide2: none,media=cdrom
memory: 8196 name:
Mailgateway net0:
e1000=DA:9A:6A:A6:76:EA,bridge=vmbr0
numa: 0
ostype: l26
sata0:
images:110/vm-110-disk-1.vmdk,size=80G
scsihw: virtio-scsi-pci
smbios1: uuid=bd6984d5-631a-4f38-a951-fce97189e68d
sockets: 2
#qmdump#map:sata0:drive-sata0:images:vmdk:

Das anderen Linux, auch auf Wortmann, hatte die Platte auf SAS-Raid5 (Intel RAID):
boot: dc
bootdisk: sata0
cores: 1
ide2: none,media=cdrom
memory: 4096
name: Kopano-MailSRV
net0: e1000=0A:A5:43:39:08:57,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
sata0: Raid5:vm-105-disk-1,size=200G
scsihw: virtio-scsi-pci
smbios1: uuid=2d9bb1c1-c310-48a8-b8ba-a9b627901dd5
sockets: 2
#qmdump#map:sata0:drive-sata0:Raid5:raw:

An die dritte Konfig komm ich so nicht ran, weil der NUC mit dem Proxmox VE abgesteckt und mit dem Techniker unterwegs ist. Die Backup-Files hätte ich allerdings im Zugriff...

 

[dcsapak]

wenn ich raten muss, würde ich sagen es liegt daran dass die disk mit sata eingebunden ist, das ist im qemu leider nicht so gut unterstützt und eigentlich nur aus kompatibiliätsgründen vorhanden

lieber scsi verwenden

 

[fireon]

wenn ich raten muss, würde ich sagen es liegt daran dass die disk mit sata eingebunden ist, das ist im qemu leider nicht so gut unterstützt und eigentlich nur aus kompatibiliätsgründen vorhanden

lieber scsi verwenden

Ja gut, das wäre aber fatal! Wenn dem wirklich so ist sollte bei SATA hier ein großes Rufzeichen stehen, mit einer Warnung.

Ich seh auch hier das ein Image auf VMDK ist, das ist natürlich auch fatal. Ist auch nur für Migrationszwecke. Und das ganze über NFS. Da könnte ein Snapshot schon alles schrotten. Sollte man wirklich ein paar Warnschilder in die GUI bauen.

EVOdrive wearout ok?

 

[Helmut Gruber]

vmdk ist natürlich kurios, da muss ich den Kollegen nochmal fragen wieso und warum.

Ist das Konsens, dass das Snapshot-Backup an dem Schlamassel schuld sein könnte?

 

[dietmar]

Uns sind keine fatalen bugs mit vmdk oder sata bekannt. Datenverlust tritt meistens bei kaputten Festplatten/SSD auf. Würde auch mal das RAM testen.

 

[Helmut Gruber]

Auf den Wortmann Maschinen laufen parallel noch mehrere Windows-Server. Augenscheinlich ohne Probleme.
Wiederlegt das die Theorie mit kaputten Festplatten / RAM?

Bisher hat es nur Linux-Guests erwischt.

 

[dietmar]

Wiederlegt das die Theorie mit kaputten Festplatten / RAM?

Nicht wirklich -das kann auch Zufall sein. Können Sie das Problem irgendwie reproduzieren?

 

[hackmann]

Hallo, ja dass hatte ich in meiner Testumgebung auch. Plötzlich waren die VMs nicht mehr da, als würden Diese garnicht vorhanden sein.
Exakt dass gleiche Problem.

Ich bin froh, dass ich nicht der einzige bin.

lieben gruss

 

[LnxBil]

Generell ist es auch immer hilfreich wenn man die Logs überwacht, denn dort stehen oft Fehler mit dem Controller (virtuell oder Hardware) schon sehr zeitig drin. Ich hatte schon oft, dass sich mal die Firmware eines RAID-Controllers verabschiedete (z.b. zu heiß wegen Klimanalagenausfall) und dann bekommt man das im schlimmsten Fall erst Tage später mit, weil das Betriebssystem ja sehr viel gecachet und so weiter. Natürlich ist alles, was dann noch geschrieben wird für die Tonne und man kann sich dann nicht mehr sicher sein, dass überhaupt noch sinnvolles - oder eben destruktives auf die Platten geschrieben wird. Generell hat man mit NFS da weniger Kontrolle was geschrieben wird und ich habe passiv im Forum schon öfters gelesen, dass es damit zu Inkonsistenzen kommt - aber ohne selbst davon je betroffen gewesen zu sein. Was ich jedoch hatte war, dass beim Backup der VMs, genauer beim Einfrieren der I/Os durch den qemu-agent, die Verbindung zu den Festplatten gestört wurde und dadurch der Gast auch ohne Festplatte da gestanden ist. In den Fällen war aber nichts an den Disks kaputt und das Problem war durch einen Neustart des Gasts zu beheben. Problem wurde aber letztes Jahr durch irgend ein Update implizit behoben.

 

[Helmut Gruber]

Eine Gemeinsamkeit hat sich aufgetan.
Alle Linux VMs sind entweder ursprünglich als VMDK angelegt worden, dann auf LVM migriert worden, oder liefen direkt aus dem VMDK File heraus.
Controllerfehler oder ähnliches hat es nicht gegeben. Die parallel laufenden Maschinen laufen nach wie vor ohne Probleme.