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.

XenServer Free Edition und der Adaptec Raid

Wir haben mal wieder einen XenServer zusammen gebaut und installiert. Auf der Seite der erfreulichen Dinge kann man vermelden, daß die Citrix XenServer 7.5 und 7.6  jetzt schon mit Adaptec-Raidcontrollersupport ausgeliefert werden, was das ganze Setup deutlich vereinfacht 🙂

„Einmal mit Profidesignern arbeiten..“

Dummerweise kam es mit dem Adaptec 8405E im 2 HE Gehäuse zu einem klitzekleinen Problem, was garantiert zu vermeiden gewesen wäre, wenn der Designer des Controllers genug Kaffee bekommen hätte.

Adaptec fertigt den 8405E in Low Profile und liefert den auch mit LP Blech aus. Schlauerweise ist die Raidpeitsche (der Kabelbaum) so konstruiert worden 😀

Der Kabelbaum geht senkrecht aus dem Controler anschluß weit über das Gehäuse hinaus und kann nicht abgewinkelt werden.Es hätte einem Ingenieur eigentlich beim Test sofort auffallen dürfen, daß das so nicht passen kann. Die hier abgebildete Peitsche ist tatsächlich im Großhandelssystem für diesen Controller als passendes Bauteil aufgelistet. Eigentlich gehört die aber zu einer alternativen 6/8er Version der Adapteccontroller, die hinten am Ende einen horizontalen Anschluß haben, wo diese steife Ausführung ohne Knick kein Problem darstellt.

So wies aussieht, gibt es einen passenden Kabelbaum von Intel mit abgewinkeltem Anschluß. Und dabei hatte der Tag so gut angefangen 😉 Dumm nur, daß der beim Handel nicht vorrätig war und so werden wir erst in 3 Tagen erfahren,  ob wir einen neuen Controller nehmen müssen 😉

XENServer – Wie man coalesce Probleme los wird

Es gibt einige echte Knackpunkte im Xen System, an denen der Admin verzweifeln kann. Einer davon ist der Coalesce-Fehler. Dieser wird ausgelöst, wenn auf der Storage kein Platz mehr ist, um das Zusammenführen von Bruchstücken einer VM durchzuführen.

EXCEPTION util.SMException, Timed out

Im SMLog  des Xenservers sieht das dann so aus :

Dec 6 02:27:17 xen SMGC: [10357] SR db4c ('Local SATA Storage') (5 VDIs in 4 VHD trees): no changes
Dec 6 02:27:17 xen SMGC: [10357] Removed leaf-coalesce from 67558d6a[VHD](2020.000G//2023.953G|ao)
Dec 6 02:27:17 xen SMGC: [10357] *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Dec 6 02:27:17 xen SMGC: [10357] ***********************
Dec 6 02:27:17 xen SMGC: [10357] * E X C E P T I O N *
Dec 6 02:27:17 xen SMGC: [10357] ***********************
Dec 6 02:27:17 xen SMGC: [10357] leaf-coalesce: EXCEPTION util.SMException, Timed out
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1435, in coalesceLeaf
Dec 6 02:27:17 xen SMGC: [10357] self._coalesceLeaf(vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1637, in _coalesceLeaf
Dec 6 02:27:17 xen SMGC: [10357] return self._liveLeafCoalesce(vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 2174, in _liveLeafCoalesce
Dec 6 02:27:17 xen SMGC: [10357] return SR._liveLeafCoalesce(self, vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1685, in _liveLeafCoalesce
Dec 6 02:27:17 xen SMGC: [10357] self._doCoalesceLeaf(vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1719, in _doCoalesceLeaf
Dec 6 02:27:17 xen SMGC: [10357] vdi._coalesceVHD(timeout)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 690, in _coalesceVHD
Dec 6 02:27:17 xen SMGC: [10357] self.sr.uuid, abortTest, VDI.POLL_INTERVAL, timeOut)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 149, in runAbortable
Dec 6 02:27:17 xen SMGC: [10357] raise util.SMException("Timed out")
Dec 6 02:27:17 xen SMGC: [10357] 
Dec 6 02:27:17 xen SMGC: [10357] *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Dec 6 02:27:17 xen SMGC: [10357] Leaf-coalesce failed, skipping
Dec 6 02:27:17 xen SMGC: [10357] Starting asynch srUpdate for SR db4c3909-4b61-e5f6-8548-16dc56780f61

„Leaf“ , das sind die losen Enden einer Festplatte einer VM, wenn man z.b. einen Snapshot der VM angefertigt hat und diesen wieder löscht. Dann wird das, was im Snapshot war, auf die Festplatte übertragen. Dazu muß aber ggf. in LVM Storage eine neue Zwischenfestplatte mit gemeinsamer Größe gebaut werden, in der die „Leafs“ gemergt werden. Das passiert auch, wenn man eine Festplatte vergrößert. Den Vorgang nennt man „Coalesce“ (Zusammenfügen)

Kein Platz mehr

Sind die Ausgangsfestplatten zu groß oder die Storage zu klein, kann XEN die Daten nicht zusammenführen und obiges passiert. Wie bekommt man jetzt Platz , ohne das man Platz hat?

Da gäbe es zwei Möglichkeiten, wovon eine trivial ist: Neue Platten an das LVM hängen und so mehr Platz in der Storage schaffen. Die zweite Möglichkeit ist auch recht einfach, die VM auf eine andere Storage kopieren und danach wieder zurück kopieren. Bei dem mit der Kopieraktion verbundenen Export werden die Daten von Xen auch aus den Leafs gemergt, nur halt an einer anderen Stelle ( dem Ziel ).

Zwischen den Kopier- oder Export/Import-Aktionen muß man dem System allerdings Zeit geben aufzuräumen. Der Befehl „xen sr-scan …sruuid…“ in der XenServer Konsole, stößt nach dem Kopieren den Coalesce-Prozess an. Nun muß man warten bis Platz ist, dann kann die VM zurück auf Ihren alten Server.

USB oder NFS

Wenn man keine zwei Storages in einem Serverhost hat, muß man kreativ werden. Da bieten sich zwei Optionen an: Externe USB Platte ( dauert ewig und drei Tage ) oder ein NFS Mount auf einem anderen Server.

Es hat sich als gute Taktik erwiesen eine Transfer-VM zu haben, auf der genug Platz ist um die anderen VMs zwischenlagern zu können. Die kann man bei Bedarf hochfahren, mounted einen Pfad per NFS, exportiert die VM da hin, räumt auf und Import sie wieder von dort. Fertig.

Kleiner Tip: Snapshots zügig wieder löschen, bevor das Platzproblem auf der Storage anfängt.