Xenserver: VDI löschen geht nicht – was tun?

Moin,

heute widmen wir uns eines kleinen Problems, daß auftreten kann, wenn beim Xenserver was richtig schlief läuft:

Beim Transfer einer VM von einem Server zum Anderen ( Stichwort: vm-import ) brach der Transfer zusammen und die importierte VM war defekt. Zu dem Zeitpunkt lies sich weder der Import abbrechen, noch störte das den zweiten Versuch. Erst beim Aufräumen der VM und Festplatten, die beim Import automatisch angelegt werden, kam es zum Problem:

Error: „This Operation Cannot be Performed Because a VDI is in Use by Some Other Operation“

Ja, ok. Und nu? Die zu löschende VM ( vm-destroy ) lies sich noch löschen, aber die daran angehängten Festplatten ( VDI ) nicht mehr. Diese wurden noch vom hängenden Import Prozess blockiert, der an der Dom0 hängt.

Hinweis: Die UUID hier sind die von meinem Server, Ihr habt andere! Die Befehle einfach so in die Konsole hauen, wird schlimmstenfalls Sachen löschen, die Ihr nicht löschen wolltet oder es passiert gar nichts 😀

Da muß man jetzt die Zähne zusammenbeißen und ein paar unfreundliche Anweisungen manuell in die Konsole hauen:

1. Damit wird der hängende Importtask endgültig terminiert:

xe-toolstack-restart

Für sich betrachtet ist der Befehl allerdings harmlos, damit geht noch nichts kaputt 😉

2. Damit sucht man sich die UUID der Festplatte raus, die man löschen will.

xe vdi-list

3. Jetzt müssen wir die VBD ( Virtual Block Device ) zu der VDI finden:

xe vbd-list vdi-uuid=bc83886b-5723-4dfe-9d5b-feebb2917d0f

Da kommt in etwa sowas raus:

uuid ( RO) : d16248e4-2c24-fa3a-1364-dcb43f5f6858
vm-uuid ( RO): 253c1fde-78d4-3719-ede6-8d0bd223b873
vm-name-label ( RO): Control domain on host: xen1
vdi-uuid ( RO): bc83886b-5723-4dfe-9d5b-feebb2917d0f
empty ( RO): false

4. Jetzt die Augen zu und durch: die VBD abziehen und löschen

xe vbd-unplug uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858
xe vbd-destroy uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858

5. und jetzt weg mit der VDI:

xe vdi-destory uuid=611441f9-20c7-6775-716a-37c78b6d672e

6. Jetzt empfehle ich noch das Storage Repository ( SR ) neu zu scannen:

xe sr-list
xe sr-scan uuid=655e2297-b012-d722-1c5f-c2814226a942

Damit wird die Liste der virtuellen Festplatten aktualisiert.

Fedora: Xen bootet endlich wieder aktuelle Kernel

Paravirtualisierte Virtuelle Maschinen eines XenServers booten endlich alle wieder die aktuellen Kernel, ein Grund zu feiern.

It’s Time to Party \o/

Die Einleitung mag dem Einen oder Anderen komisch vorkommen, aber auf den Tag habe ich lange warten müssen. Seit einiger Zeit booteten die Kernels von Fedora nicht auf Paravirtualsierten VMs vom XenServer. Zudem liefen die Kernel 4.16.x bis 5.0.0 echt instabil, so daß diese sich nach Stunden bereits reseteten. Richtig gelesen RESET, nicht Crash. Das ist so ziemlich die mieseste Art eines Kernelbugs, da man nicht mal sehen kann, was da wo gecrasht ist.

Unzählige Bugreports an RedHat und Citrix später ist nun endlich soweit, die aktuellen Kernel 5.0.16 laufen stabil und, das beste daran, booten überhaupt wieder auf allen XenServer-Versionen.

Damit bekommen die VMs auch die neueste Firmware für die CPUs mit und angesichts diverser neuer Intel-CPU Schwachstellen, eine wirklich beruhigende Angelegenheit. Daher 😀

 

Alternativ die Studioversion von Andrew W.K.’s Time to Party!

Ich finde ja den Live Sound trotz der Störgeräusche einfach besser. Das der als Band ein ganzes Stadion gefüllt hat, will man kaum glauben, oder? 😉

XenServer zu alt um Kernel 5.0 zu laden

Wer XenServer und Kernel 5.0.x einsetzen will, sollte jetzt gut aufpassen, sonst => VM Streik

Kernelimage zu neu für XenServer 6.2.x

Da es sich um etwas handelt, daß international wichtig sein könnte, gibts das auf Deutsch und English,
so don’t wonder if you just understand halve of it 😉

Ihr wollt Eure VM booten, bekommt aber diesen Fehler?
You wanne boot your VM and get this message ?

xenopsd internal error: XenguestHelper.Xenctrl_dom_linux_build_failure(2, “ panic: xc_dom_core.c:616: xc_dom_find_loader: no loader\\\““)

Das passiert, weil das Kernelimage mit einer neuen Compressionmethode gepackt wurde, die das alte XEN nicht kann.  The reason is, that your kernel image file is compressed with a new algorithm, your old XEN can’t handle.

Als erstes brauchen wir die UUID der VM:
First, get the UUID of your VM:

xe vm-list | grep -A5 -B5 <vmname>

Um das zu beheben, braucht man den Befehl: xe-edit-bootloader.sh -u uuid
To fix your vm, you need to execute : xe-edit-bootloader.sh -u uuid

/root/xe-edit-bootloader.patched.sh -u 317fb132-283a-56c6-1627-8b39cf944148 -p 1

Nun kann man die Reihenfolge der Bootmenüeinträge so ändern, daß der bisherige Kernel vorn steht. Dann speichern und Editor beenden und jetzt sollte die VM auch wieder starten.
Now you can change the order of your grub menuentries to the last working kernel being first. When you have saved and exited the editor, the parition will be unmounted and you can start your VM again.

Tipps – Additional hints for you

Der Befehl mountet die Systemplatte der VM und lädt die gebräuchliste grub.conf. Das wird aber vermutlich nicht auf anhieb klappen. Man muß etwas über das Festplattenlayout der VM wissen:
This will mount your VM’s main disk and access the most likely location of your grub.conf, but that will not work without your knowlage of the VMs structure:

-p: Partition number to mount (default: none)
-f: Location of bootloader config file to edit

Wenn man eine traditionelle SDA1 SDA2 Partitionierung in der VM hat, dann gibt man -p die Partitionsnummer der Platte an, wo man /boot/ finden kann. Wer LVM in der VM benutzt, dürfte jetzt so ziemlich am Arsch sein. Kleiner Tip, exportiert die VM auf einen neuern XenServer.

If you have a sda1 and sda2, where sda2 is swap, that -p 1 will mount partition 1 and your good to go.
If you have i.e. a seperate boot partition, you need to know it’s number.
IN CASE you have LVM inside your VM, i guess your screwed now. In this case, export it to a newer XenServer Version.

Weil sich Grub1+2 ein bisschen uneinig wegen der Verzeichnispfade sind, kann man Position der grub.cfg mit -f angeben. Wer eine eigene /boot Partition hat, braucht dann nicht /boot/ hinschreiben, -f grub2/grub.cfg reicht.

Grub1+2 differ a bit, where to find the grub.conf file. Thats where -f will be handy. You can just tell it, if you knew it: -f /boot/grub2/grub.cfg   should usally work, except, you are already on /boot (seperate partition) then it’s just -f grub2/grub.cfg .  As theres only a texteditor loaded, you could try to change other files too 😉

Ich habe einen gepatchten xe-edit-bootloader, der mir erlaubt, gleich die ganze Platte in Dom0 zu mounten. d.h. ich kann alles in der VM anpassen, nicht nur Textdateien, was extrem praktisch ist.
Why is my xe-edit-bootloader.sh  patched? because i adapted it to just mount the disk and wait for me to explore the disk. That’s so helpfull, you won’t believe it.

Bei einigen Systemen kann durch setzen der $EDITOR Variablen auf „/bin/bash“ eine Shell bekommen, aber ich rate davon ab, daß auf Produktivsystemen auszuprobieren, das könnte böse Nebenwirkungen haben.
In rare cases it’s possible to trick the script with the $EDITOR variable set to „/bin/bash“ to open a bash shell for you, but i really suggest not to mess with your dom0 on a production system.