No bootable device - migrierte Server lassen sich nicht rebooten

[Romsch]

Hallo zusammen!
Wir haben ca. 20 VMs in einem dreier Cluster mit Ceph am laufen.
Die hälfte der VMs wurde mit Clonezilla migriert, P2V, die andere hälfte habe ich zu raw convertiert von vmware.
Nun das Problem. Vor ein paar Wochen hat sich eine Ubuntu 18.04. VM aufgehängt, diese wurde von vmware convertiert, lief ohne Probleme. Ein Stop der VM war nötig, da sie nicht mehr erreichbar war. Aber nach klicken von Start der VM, kam der Bootscreen mit der Meldung no bootable device...
Eine Woche später eine migrierte VM, SLES 12, es scheint als würde die VM eingefroren sein. Auch hier hilft nur ein Stop und Start der VM. Der selbe Effekt, kein bootable device. Und heute die dritte VM, ebenso scheint sie im freeze state gewesen zu sein. Kein reboot möglich.
Ich habe etliche boot/live iso tools versucht, um die VM bzw. auf die eigentliche Partition zugreifen zu können, aber immer vergebens, die vm bzw. die Festplatte ist einfach komplett leer/nicht lesbar.
Es half hier nur das letzte Backup einzuspielen, das funktionierte bei zwei VMs, bei einer war sogar das Backup nicht mehr brauchbar.
Hatte jemand ähnliche "Erfahrungen", das sich nach einem "aufhänger", kernel panic oder anderem verhalten, die VM bzw. die Festplatte nicht mehr lesbar/bootfähig ist?
Ich hatte nie so ein problem in der Vergangenheit, warum sind die "daten" der Vm nach einem reboot einfach weg?

Vielen dank für euer feedback.

PVE 5.4-13, alle Knoten sind up to date.
Ceph 12.2.12 mit 21 osds (je 1TB), dreifachverteilung, 1024pg_num/pgp_num



EDIT: Es könnte an den Backupjobs bzw. Backupstarts liegen - laut graphen passierte das immer, sobald die VM gebackupt wird - zumindest hat es sich bei den Vorfällen so verhalten.

 

[Ulrich]

Hallo,
wir haben vermutlich das gleiche Problem. Wir 20 Hosts im Cluster und jetzt bereits den dritten und vierten Gast, der nach einem Neustart des Hosts nicht mehr hochfährt mit "no bootable device". Bei den ersten beiden Fällen half ein Restore aber jetzt scheinen auch diese defekt zu sein. Wir haben versucht die qcow2 images mittls nbd zu mounten bekommen aber immer bad superblock.

Erst ein 3 Wochen altes Backup konnte erfolgreich wiederhergestellt werden.
Ein Server bleibt (bisher) unwiederbringlich verloren.

Gibt es hier Hinweise, was da passiert?

Freue mich auf Antworten.

 

[Romsch]

Hallo, nein nicht wirklich, hab bei proxmox support ein Ticket dafür noch offen.
Es gibt einen Lösungsweg um die VMs wieder bootbar zu machen, hab dafür eine Anleitung für uns intern erstellt.

Aber was da passiert ist, weiß ich nicht wirklich.

D. h. das aufsplitten der Backupjobs hat es gelöst? Oder wie backupt ihr momentan?

Viele Grüße,

Roman

 

[Ulrich]

Wir haben noch keine Lösung. Können wir von eurer Anleitung profitieren?

Die Backups kommen von 2 verschiedenen Servern aber die erfolgreichen Restores kamen vom gleichen Server, wie die erfolglosen Restores.
Gruß,
Ulrich

 

[Romsch]

Wir haben es so gelöst, die Problem-VM mit "gparted" booten, dort in einem Terminal mit Root Rechten "testdisk" starten. Testdisk schafft es, die verschwundenen bzw. verlorenen Partitionen wiederherzustellen. Im Anschluß ein Reboot mit einer anderen ISO, "Boot-Repair-Disk", diese schafft es dann den Bootloader wieder komplett herzustellen.
Ich kann Dir die Anleitung auch gern zukommen lassen. Ist ein Workaround, aber momentan sieht es gut aus mit den Backups, seit dem wir jeden Knoten einzeln sichern lassen. Parallel Backup mehrerer Knoten zeigt wieder den komischen Effekt an einigen VMs an.

viele Grüße,
Roman

 

[Ulrich]

Für die Anleitung wäre ich Dir sehr dankbar. Dann müssen wir den Weg nicht selber finden. Was meinst du mit Backupd einzelner Knoten? Wir haben die Backups an jedem Guest einzeln konfiguriert.

Gruß,
Uli

 

[Romsch]

Diese Einstellung macht bei uns Probleme:





Diese Backupeinstellung -jeden einzelnen Knoten für sich- funktioniert, seit zwei Wochen keine probleme mehr:



Anleitung für Restore "no bootable device" kann ich Dir schicken, die ist zu groß zum hochladen..

 

[h4rry]

Hallo, könntet ihr mir die Anleitung zum wiederherstellen des Bootloaders zukommen lassen?
Währe euch sehr dankbar

 

[TheMrg]

Wir haben gerade das selbe Problem. Wie konnte es gelöst werden?

 

[gmed]

MBR etc. lassen sich z.B. via gparted-Boot-CD und dann mittels testdisk ganz gut wiederherstellen.

https://www.howtoforge.de/anleitung/datenwiederherstellung-mit-testdisk/

Eine Frage in die Runde:
Nutzt jeder, welcher Probleme hat noch PVE 5.4-XX oder tritt es auch bei aktuellen Versionen auf?

Wir hatten das Phänomen auch und konnten es durch splitten der Backups lösen.
Wobei ein Backuplauf mit 2 VM's auf einmal bei uns gut funktioniert.

 

[TheMrg]

Danke, wir konnten in der Nacht schon die 2VMs retten. Allerdings einiges an Arbeit.
Wir denken auch nicht, dass es mit dem Backups zusammenhängt. Eher ein Ceph timeout was einige Tage zuvor aufgetreten ist (kurze Netzwerkstörung). Sicher sind wir aber nicht, lässt sich sehr schwer rekonstruieren.

 

[studiofunk]

Moin,
wir haben seit einigen Wochen das gleiche Problem. Es ist plötzlich aufgetreten, ohne dass wir etwas verändert haben...
Seid ihr schon dahintergekommen, wo das Problem mit Ceph beim Migrieren liegt? Was für Cache-Einstellungen nutzt ihr? Hängt das vielleicht damit zusammen oder ist das unabhängig davon?

 

[Romsch]

Hi,
seit Version 6.x kommt das "Problem" nicht mehr.
Für Ceph sollte empfohlenerweise kein Cache eingestellt sein.

 

[Sourcenux]

Wir haben das Problem heute bei einer VM unter PVE 6.4 erlebt. Der Speicher lag auf einem NFS Laufwerk und die Festplatte war per SATA an die VM gebunden (sata0). Nach der Neuinstallation des Bootloaders und der Wiederherstellung durch Testdisk lief die VM wieder.

 

[RolandK]

der bugreport unter https://bugzilla.proxmox.com/show_bug.cgi?id=2874 sieht ähnlich aus.

macht mich irgendwie nervös...

 

[Tardar]

Ich habe das problem auch ständig, dass ich den Bootloader wiederherstellen muss.
Das nervt echt gewaltig, gerade wenn das erst später auffällt, weil der Server nicht jeden Tag neugestartet wird.

 

[RolandK]

das nervt nicht , daß ist ein echtes problem.

@Tardar kannst du bitte input dazu liefern? dein setup genau beschreiben und das fehlerbild ? wo es auftritt, unter welchen umständen oder ob du es womöglich reproduzieren kannst?

am besten direkt im bugzilla ticket.

falls das nicht möglich ist, hier, dann werde ich vom bugzilla eintrag auf diesen foren eintrag verweisen.

wir haben immer noch keinen repro-case

 

[RolandK]

@Romsch , @studiofunk , @Sourcenux besteht bei Euch das Problem noch und könnt ihr dazu auch noch möglichst viel Input liefern ?

 

[Tardar]

das nervt nicht , daß ist ein echtes problem.

@Tardar kannst du bitte input dazu liefern? dein setup genau beschreiben und das fehlerbild ? wo es auftritt, unter welchen umständen oder ob du es womöglich reproduzieren kannst?

am besten direkt im bugzilla ticket.

falls das nicht möglich ist, hier, dann werde ich vom bugzilla eintrag auf diesen foren eintrag verweisen.

wir haben immer noch keinen repro-case

Bin mir nicht sicher.

Meine These, nach dem was ich beobachtet habe:
Es tritt nach nächtlichen Backups auf (allerdings nicht bei allen Maschinen).
Ob es nur bei fehlgeschlagenen auftritt oder auch bei erfolgreichen vermag ich aktuell nicht zu sagen.

Meist fällt es mir immer nur dann auf, wenn Dienste nicht mehr korrekt agieren, aber noch erreichbar sind.
In der proxmox Konsole der Maschine häufen sich dann Fehlermeldungen - dabei bin ich mir nicht sicher, ob es an Proxmox oder ggf. an einer SSD liegt, die vom Server Betreiber (in meinem Fall hetzner) nicht als defekt deklariert wurde.

Wenn ich mit konkreten usecases beisteurn kann, die wir aufstellen können, können wir vielleicht versuchen das reproduzierbar zu machen.

 

[Sourcenux]

Bei uns ist das Problem in letzter Zeit nicht mehr aufgetreten. Wir haben alle Systeme vor ca. 2-3 Monaten neugestartet, da im Haus an der Elektrik gearbeitet wurde. Das letzte mal, als es aufgetreten ist, handelte es sich um eine Debian 6 VM - Die machen manchmal auch Probleme, wenn man sie migriert oder Snapshots anlegt oder generell irgendeine Art von IO-Verzögerung auftritt. Dann gibt es idR. eine Kernel-Panic. Als Storage Backend verwenden wir Ceph (damals noch mit octopus).