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.