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.

Fröhliche Bugzeit Euch allen

Fröhliche Bugzeit meine Lieben \o/ .. „Hey, Sie da!“ „ähh, ja?“ „Sollte das nicht Backzeit heißen?“ „Nein, das ist schließlich ein IT-Blog und keine Bäckerei!“

Fröhliche Bugzeit allerseits!

Alle Jahre wieder kommt die Bugzeit über uns. Derzeit sind es besonders viele Bugs in Fedora 28 und seit gestern, habe ich auch noch 4 Bugreports bei EBAY laufen und ich meine echte Anwendungsfehler. Da werden harmlose Bewertungstexte als vulgär bezeichnet, Nachrichten des Supports erreichen uns als HTML-CODE, falsche Fehlermeldungen eingeblendet, die mit der Sachlage nichts zu tun haben, und anderer Krams.

Auf der Fedorafront kommt ein Cinnamon Bug hinzu, der Icons von Programmen in der Leiste verschwinden läßt, Cairo wird für F29/30, aber nicht für F28 aktualisiert, weswegen F28 noch einen Bug mehr hat, als es bräuchte. Zu allem Überfluß hatte Skype dann heute auch einen technischen Ausfall, weil es Anrufe nur simuliert, statt sie durchzuführen 🙁

Der Hohn ist aber ein neues Meldegesetz für IT-Sicherheitslücken des Bundes! Als wenn von denen jemand wüßte wie das geht, geschweige denn, wie langwierig und kräftezehrend so ein Bugreport sein kann 😀

Und da sag noch mal wer, man solle nicht in Sarkasmus verfallen, bei soviel gehäuften Fehlverhalten. Manchmal glaube ich, daß es an ein Wunder grenzt, daß wegen der vielen Softwarebugs keine Leute sterben.

 

Fedora 28 Bugs wie eine Betaversion

…und da meinte neulich jemand zu mir, daß man auf Fedora 29 updaten sollte, weil Fedora 27 EOL hatte…

1 Jahres Zyklus von Fedora

{...boar ist der Gutenbergeditor Scheisse...} Wie Ihr ja gelesen habt, war Anfang Dezember EOL von Fedora 27 und man durfte Upgraden. Wie immer upgrade ich in die 2 Hälfte des einjährigen Wartungszykluses rein, in der Hoffnung, daß die in den ersten 6 Monaten wenigstens die dicken Bugs bereinigt haben.

Dies Jahr hatte ich kein Glück. Ich komme mir vor, wie ein Betatester:

Audacity stürzt up, wenn man das „Höhen und Tiefen“ Plugin anwenden will,
Texte sind in Cinnamon nicht übersetzt,
das GLIBC Paket für Deutsch wird nicht installiert, weil gloriatorisch einer dachte, der „glibc-all-langpacks“ wäre installiert, was er nicht war,
dann fliegt einem die Gnome-Shell um die Ohren und zwar mit Status „gestorben“,
das Menüicon von Cinnamon verschwindet, muß man erst wieder selbst fixen,
in der Cinnamon-Iconleiste sind die Icons per Default zugroß gerendert, so daß es aussieht, als wenn ein Mensch ohne Geschmackssinn am Werk war,
wenn man das Default Hintergrundbild für den Desktop hatte und es einem am Herzen lag, mein Beileid..
die Kernelmodule beim Booten laden immer noch nicht,
auf Laptops ist die Bildschirmauflösung zwischen GRUB und GDM in die 640×480 Steinzeit zurück gebombt worden( nicht fixbar derzeit )

und so gehts weiter und weiter. Wenn das der Zustand nach 6 Monaten ist, möchte ich nicht wissen, in welchem das an Tag 1 war und in welchem Fedora 29 jetzt gerade ist. Wenn mal was nicht geht, ok, aber soviel habe ich zuletzt bei F21 gefunden.


Update 1 Tag später:

6 neue Bugreports über F28 dazu gekommen 🙁 Es wird immer mehr zu einer Alphabersion, je länger man nachsieht.

Classic Editor is back

Ich hab es wirklich versucht, aber der neue Editor „Gutenberg“ von WordPress ist eine Qual. Das tut in der Seele weh. Wie kommt man nur auf sowas? Alleine schon die Optik hat mit Texte schreiben nichts zu tun. Diese Blocktechnik ist was für Facebook-Timelime-Kids u.V. .

Classic Editor reaktivieren

Da mit Gutenberg jeder seine eigenen schlimmen Erfahrungen gemacht hat oder noch machen wird, wenden wir uns produktiveren Dingen: Wie wird man ihn los?

Das ist zum Glück ganz einfach!

Im Dashboard unter Plugins „Installieren“ auswählen und in das Suchfeld „Editor“ eingeben. Kommt als erster Treffer mit über 1 Million Installationen „Classic Editor“ 😀 Alles mit OK bestätigen und Fertig.

Ich habe so das Gefühl, daß wird mit weitem Abstand das beliebteste Plugin werden.

Meine wenig positive Meinung  werde ich hier nicht zurückhalten: WP werdet die Typen los, die das verbrochen haben!

Die Aussichten bis 2020

Da die Menschheit ja bei wichtigen Entscheidungen immer die schlechtere Option wählt, haben besorgte Blogschreiber WP geforkt und lassen es ohne Gutenberg weiter laufen. GGF. muß man das in Zukunft als Option wählen, wenn man einfach nur Blogs schreiben will. Im Gutenberg habe ich nicht mal die Rechtschreibkontrolle gefunden, und das viele unnötige rumgeklickte um substanzielle Funktion zu erreichen. Wo es doch vorher super funktioniert hat. Das kommt bestimmt aus der Ecke der Handy und Tablelike-Benutzer mit Minibildschirmen. Als wenn das die Hauptgruppe der Blogschreiber wäre. Das wäre mir viel zu anstrengend mit den virtuellen Tastaturen. Wobei, „Diktieren“ ist ganz nett, führt aber meiner Erfahrung nach zu schlechtem Satzbau, so daß man viel editieren muß.

LAHA und die Latenzfalle

Kleines Update zu LAHA, dem Multiroom Sound und PulseAudio.

Stand der Dinge

Wie man es drehen und wenden will, die fertigen Tools zum Abspielen von PCM Sound haben alle irgendeine Macke.

PAPLAY benutzt PulseAudio. Das ist praktisch ein Todesurteil für eine stabile Latenz.
APLAY   benutzt Alsa, das defaultmäßig … PulseAudio benutzt. Siehe erstens 🙂
*JACK*  nun Jack möchte gern alleine tätig sein, ohne Konkurrenz. Fällt auch aus.

Da APLAY und PAPLAY per Default einen PA Stream zum Abspielen benutzen, haben beide in der Form das gleiche Problem: Die Audiolatenz des Playstreams steigt mit der Zeit an. d.b. alle anderen Geräte müßten mitwandern. Blöd nur, das Androids gar keine Latenzwanderung haben und selbst wenn Sie es hätten, wäre das eine blödsinnige Lösung. Jetzt fragt Ihr Euch natürlich: was labbert der da? Da muß man jetzt weiiiiiit ausholen.

Also, wenn man mit PAPLAY Sound ausgibt, geht PAPLAY zum PAServer und sagt dem, das DER eine Latenz wählen soll. Das macht der dann auch, nachdem die ersten Daten geflossen sind und die pegelt sich mit 16Bit Stereo und 48000″hz“ bei rund 1,9s ein. Richtig gelesen 1,9 Sekunden. Nach 40 Minuten sind wir bei knappen 5 Sekunden, wenns dumm läuft. Wenns gut läuft bei 2,4s . Das entscheidet PA selbst, ich nehme an, nach internen Fehlberechnungen aller gestarteten, gestoppten, bewegten etc. Streams die auf dem System drauf sind. Ich hab es noch nicht im Source gefunden. Es ist eigentlich das Ziel eines Audioservers die Latenz niedrig zu halten, aus irgendeinem Grund, ist dem PA-Latenzalgorithmus das egal.

Wenn man jetzt denkt, daß der Befehl ja eine OPTION für die gewünschte Latenz hat und sich schon freut, daß die dann ja als Ziel eingehalten wird .. ähm ja, also wie soll ich das Schreiben ohne verklagt zu werden??? Lieber nicht, hier ein Beispiel: 500ms angegeben, Latenz beginnt bei 320ms und wandert pö-â-pö so Richtung 500ms, durchbricht den Median, und verschwindet alsbald jenseits von Gut und Böse im Sekundenbereich.

Wenn man auf die glorreiche Idee kommt, da das anzugeben, was der Algo vorher selbst ausgerechnet hat, dann bekommt man nicht 1,9s , nö, mehr so 1s+- und dann kommt das gleiche Spiel wie vorher bei 500ms.
Ja, man könnte jetzt die PAPLAY-Routine kapern, den anderen Geräten die Latenzen mitteilen und denen somit zu einem Sync verhelfen. ABER.. die Latenz wird ja immer größer, was bedeutet, daß bei jedem neuen Sync mehr Zeit vergeht, bis man was hört. Also auch mal 5 Sekunden schwarzes nichts. Das ist hochgradig Inakzeptabel.

Bugreports sind raus, werden nicht helfen, weil (C) endet 2006 . Sieht nicht so aus, als wenn da wer dran arbeitet.

Kommen wir zu ALSA

APLAY kann ALSA-Devices direkt ansprechen. Warum nutzen wir dann nicht APLAY, statt PAPLAY ? Gesagt, getan. Versuchts mal, viel Glück dabei. Das geht mit etwas Glück genau einmal und auch nur auf einem Device, aus das PA grade nichts ausgibt. Ist auch klar, weil PA ja ALSA als Unterbau hat. Wir erinnern uns, daß PAPLAY 1,9s Latenz hatte. APLAY, wenn man ein Device findet, das geht, hat 0ms und das Startdelay ist nicht ganz so funktional, wie sich APLAY das wünscht aka. auch buggy. ABER, 0ms sind cool, weil Android auch 0ms haben kann, ohne dabei drauf zu gehen. Der Lesezugriff für Netzwerkdaten für „16 Bit Stereo 48k“ auf einem Android liegt bei 1ms. d.b. nimmt man ALSA als Player und bekommt das Device frei, hat man eine echt geile Latenz von 1-2ms und das hört man nicht!

Der Resync

Jetzt gibt es allerlei Hürden, die man umschiffen muß. Androids fliegt das eigene Multitasking um die Ohren, da fängt der Ton dann an zu stottern. Vorwarnung : keine. Gegenmaßnahmen: derzeit unbekannt.Das funktioniert auf dem Desktop etwas besser.

Bei 0ms Latenz ist der Resync instant, da könnte man versucht sein, einfach pauschal alle paar Sekunden mal helfend durch einen Socket.close();Socket.connect() einzugreifen. Könnte klappen, muß nicht.Ist aber eine Option, wenn der Wiedergabetask das nicht merkt. Geheimtip: Vorsicht vor doppelten Daten im AudioBuffer. Vergleicht mal, ob Ihr nach dem connect()+read() einen Teil davon schon habt und schmeißt den raus.

LAHA

Unser ControllCenter steuert jetzt bereits beliebig viele Devices, kann Audiostreams von laufenden Apps kapern, z.b. MPV, FireFox etc. , hat diverse Backends zum Abspielen auf dem Desktop, könnte verschiedene Musikplayer als Quelle nutzen und damit auch Last.FM, Spotify etc. realisieren. Er verschiebt Metadaten, findet neue Geräte im Netz, erlaubt Endgeräten mit Screen ihn fernzusteuern und hat bereits erfolgreich ein Handy als Drahtloskopfhörer für Videos laufen gehabt. Dank MPVs negativer Latenz und der frei einstellbaren Endgeräte Latenz, kann man alles perfekt ausrichten 🙂

Wir sind also auf dem richtigen Weg. Ob das allerdings vor Weihnachten 100% zuverlässig läuft, kann ich nicht garantieren. Trotz des ganzen Frustes mit den Bugs der Anderen, hat das Projekt endlich mal wieder Spaß beim Programmieren beschert. Und das ist doch, weswegen man es tut, oder nicht 😀