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

Helmut Gruber

Active Member
Jun 30, 2016
17
0
41
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?
 
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?
 
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...
 
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
 
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?
 
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?
 
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.
 
  • Like
Reactions: fireon
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.
 
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
 
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.
 
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.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!