Blogging reloaded » Xen

OSX und Terminal von Xen

Denny — Sat, 24 Sep 2011 13:34:41 +0000

Will man aus einer VM wieder heraus, die mit “xm create -c” od. “xm console vm” betreten wurde, hilft unter OSX die Kombination CTRL+ALT+6. Geklaut von hier

Notiz: Xen + Hetzner + IPv6 + Routing

Denny — Thu, 15 Jul 2010 20:49:18 +0000

Hat man das IPV6 Netz von Hetzner, kann man das natürlich gleich mit Xen verwursten. Dazu habe ich mit Hilfe diverser Anleitungen und Foren mal eine kleine Anleitung geschrieben, wie man ein geroutetes Netz mittels IPv6 und Xen hinbekommt.

http://www.pug.org/mediawiki/index.php/IPV6/xen-route

Bei Missverständnissen oder Fehlern einfach melden od. selbst korrigieren.

Offline heute nacht

Denny — Sun, 07 Jun 2009 09:59:21 +0000

also ich beobachte das schon seit einigr Zeit: LVM ist noch nicht so ganz stabil, also zumindest vom Debian Xen Kernel. Für die Backups der DomUs wird ein LVM Snapshot erstellt, um dann von dort Tar Backups zu ziehen. Hier und da tauchen dann mal ganz ekelhafte Backtraces auf, die sich definitiv auf das LVM beziehen.

Soweit habe ich die wichtigsten Dienste wieder hochgefahren. Mal sehen, ob sich das mit dem Update gebessert hat.

LVM unter Etch, irgendwie kaputt

Denny — Thu, 12 Mar 2009 12:51:31 +0000

Ich werde den Verdacht nicht los, dass das Konstrukt LVM, Device-Mapper und Udev unter Echt kaputt ist. Schon seit einiger Zeit bin ich nicht mehr in der Lage, LVM Snapshots sicher zu erstellen. Mal klappt es, mal nicht. Schuld ist angeblich eine Udev Regel. Ändert man wie beschrieben den ACTION von “add” nach “change” um, klappt es wieder. Dafür hat dann meine Xen DomU ein Problem. Sie kann dann nicht mehr auf das Volume zugreifen. Ein Input/Output Fehler meldet sich dazu. … ich schätze, ich muss dochmal ein Upgrade auf Lenny testen …

Hardy: Xen 3.3 mit DRBD Block Gerät

Denny — Fri, 28 Nov 2008 15:21:20 +0000

Nur eine Notiz:

Wer unter Hardy Xen betreiben möchte, aus dem Multiverse Zweig, der möchte eventuell DRBD in der DomU Config als Block Gerät angeben, nach dem Schema: drbd:ressource:xvda,w. Damit das klappt, muss man die Datei /usr/lib/python2.5/site-packages/xen/xend/server/blkif.py anpassen. Sucht einfach nach dem Ausschnitt:

              (typ, params) = string.split(uname, ':', 1)
              if typ not in ('phy', 'file', 'tap'):
                  raise VmError(
                      'Block device must have "phy", "file" or "tap" '
                      'specified to type')

und fügt am Ende der Liste einfach noch ein “drbd” ein. Danach startet ihr den Xend Daemon neu und dann könnt ihr euren Gast migrieren. Wenn ihr active-active auf beiden Seiten habt, sogar online. Eine ausführliche Anleitung folgt noch.

Xen 3.x in Vmware Workstation/Server mit Xen Bridge

Denny — Mon, 17 Nov 2008 00:34:52 +0000

Manchmal dauert es einfach länger, bis man auf die Lösung kommt. Wer zu Testzwecken sein Xen mit auf Reisen nehmen möchte und dazu Vmware Workstation/Server verwendet, hat sich sicher schon gefragt, warum eine Bridge Konfiguration innerhalb von Vmware einfach nicht funktioniert. Es ist so logisch und die Lösung noch einfacher: Xen versetzt die Netzwerkkarte bekannterweise in den Promiscuous Mode, wenn nun aber Vmware als Benutzer gestartet wird, ist es ihm nicht gestattet das Gerät /dev/vmnet0 (meist die Bridge Netzwerkkarte von Vmware) in den entsprechenden Zustand zu versetzen. Also sollte man einfach eine Gruppe anlegen – z.B. vmware – den od. die entsprechenden User dazu setzen und die Berechtigungen auf 660 und Gruppe Vmware ändern. Nach einem erneuten Einloggen funktioniert dann auch die Xen Bridge innerhalb von Vmware wie gewünscht. Und somit bleibt die Freundin davor verschont, den Windows PC mit Vmware mitten in der Nacht einzuschalten.

Und sobald meine udev Regel funktioniert, liefere ich sie natürlich nach.

Kennt ihr das nicht auch?

Denny — Sun, 16 Nov 2008 21:18:02 +0000

Seit ich meine letzte Xen Anleitung veröffentlicht habe, erschien gerade Xen 3.1, wobei ich persönlich 3.0.4 bevorzugt habe. Nun, Monate später schaue ich erneut nach, und wir haben Xen 3.3 – wobei mir das Erscheinen selbst natürlich nicht entgangen ist, dank Heise, Golem und Co. Doch, wenn ich mir die Liste der Funktionen anschaue, komme ich aus dem Staunen kaum heraus. Vor allem soll ja nun die Live Migration von Windows sauber funktionieren, nicht dass es mir keine Freude bereitet hätte, Windows einfach verschwinden zu sehen, aber Kunden mögen zuweilen dieses Verhalten nicht.
In der Mailingliste habe ich dann auch noch eine Mail entdeckt, in der ISCSI Geräte direkt angesprochen worden sind. Leider habe ich dazu nichts offiziellen gefunden. Was mich jedoch nicht weiter verwundert, ist doch die Xen Dokumentation so beschissen wie eh und je.
Wie ich aus zuverlässiger Quelle erfahren habe, ist aber auch schon die zweite Auflage meines Lieblings- Buches auf dem Weg. Es wird dann sicher nächstes Jahr erscheinen.

Richtig spannend wird es aber, seit DRDB 8.0.6 nativen Xen Support beherrscht. Das bedeutet, ich muss die DRBD Geräte nicht mehr als /dev/drbd0 etc. eintragen und mich dann selbst um das Primary und Secondary Geraffel kümmern (besonders wichtig bei HA), sondern die DRBD Scripte nehmen mir diese Arbeit ab. Damit kann man nun auf ein Clusterdateisystem verzichten, welches nötig war um ein HA System aufbauen zu können. Und natürlich ist es kein Problem LVM darunter zu klatschen, man will ja flexibel bleiben.
Oh man, mich kribbelt es wieder an den unmöglichsten Stellen. Wird zeit, dass endlich Weihnachten vor der Tür steht um dann meiner Anleitung einen neuen Anstrich zu verpassen.

Neue Themen sind dann definitiv HA Cluster, mit Heartbeat, Überwachung seitens Nagios und Co. Wie viel Urlaub habe ich eigentlich noch?

Und das Grauen beginnt

Denny — Sat, 07 Jun 2008 12:38:37 +0000

ich habe es geahnt. Mit der Übernahme von Xen von Citrix landen bereits die Ersten auf der Straße der Informationslosigkeit (nicht das Xen da je ein Vorreiter gewesen wäre). Vor einigen Tagen erhielt ich über Jabber eine Frage, ob ich denn wüsste, warum denn DomUs nicht mehr ins Netzwerk kämen, unter Xen 3.2. Wie es scheint, wurde das Netzwerksetup wieder komplett über den Haufen geworfen*. Was verinnerlicht wurde, ist nun wieder Geschichte. Was mich vor allem so richtig stört: keiner der Entwickler sieht sich mal genötigt, auf die Frage hin, was denn nun tatsächlich der Auslöser war, das bisherige Konzept zu verwerfen (womit sehr viele, sehr gut zurecht gekommen sind), zu beantworten. Stattdessen nur Ratlosigkeit. Auf der Liste ist nun häufiger davon die Rede, bei Xen 3.1 zu verbleiben, da sonst viele Scripte etc. nicht mehr funktionieren.
Nirgends ist dokumentiert (od. zumindest nicht in der Doku/ im Wiki) wie nun das aktuelle Konzept aussieht. Also heißt es sich die Scripte anzuschauen und zu rätseln.

Ich glaube so allmählich, wenn KVM und Co Live Migration beherrschen würden, dann würde es düster aussehen, für Xen. Aber solang Xen immer noch billiger ist als Vmware, wird Xen nicht verschwinden.

* Das Bisherige Setup bestand darin, eine Bridge zu erzeugen, die Netzwerkkarte zu einem “Netzwerkstecker” zu degradieren, eine virtuelle eth0 zu erstellen, mit den ursprünglichen Daten der ehemals echten eth0, und das Gegenstück der virtuellen mit dem “physischen Stecker” in die Bridge zu werfen. Das jetzige Setup ähnelt sehr dem Konzept, was wir mit Xen 2.0.7 hatten. Dort ist die Bridge die Netzwerkkarte selbst (also kein xenbr0 sondern wird eth0 genannt). Vor allem hat nun die Bridge wieder eine IP.

(ps. vermutlich wäre es auch geschehen, wenn Citrix nicht XenSource gekauft hätte, aber das Feindbild muss geschürt werden ..)

Wenn es etwas gibt, was ich nicht leiden kann ….

Denny — Sat, 15 Mar 2008 07:40:44 +0000

… dann sind das Probleme, die sich scheinbar im Nichts auflösen. So geschehen am Donnerstag. Kurz vor dem Verschwinden vom Arbeitsplatz, sollten eben noch schnell Mails syncronisiert werden. »mail.4lin.net Timeout« Sowas mag man mal garnicht. Ein Blick auf mein Blog – oder vielmehr ein vergeblicher Blick – ließ erkennen, dass der Root Probleme hatte. Also eben schnell eingeloggt – 10 Minuten bevor die U-Bahn kam – und gesehen, sowohl Dom0 als auch die DomUs waren vorhanden und ich konnte sie intern anpingen und per SSH auf ihnen arbeiten. Was nicht ging, war das Netzwerk über NAT und Routing. ein »dmesg« zeigte ein paar Plattenfehler und daher mal ein Reboot mit anschließendem »fsck« laufen lassen. Das allerdings ohne mich.
Später nach dem Reboot ging das Netzwerk nachwievor nicht, so teilte mir das S.aus G. mit, bei der ich mich herzlich bedanken und entschuldigen will. Denn zum einen war ich furchtbar genervt und zum anderen hat sie dennoch tapfer durchgehalten und mir geholfen Danke nochmal, S. aus G. !
Wie auch immer, kurz vor DA Ankunft (mein Privates Handy war nun natürlich leer) klingelt es auf Handy Zwei und S. teilt mir mit, dass es wieder geht, ohne Einwirkung von Außen. Meine Sätze haben sicher in der S-Bahn für Irritation gesorgt, dass sich jemand darüber beklagt, wenn alles wieder geht. Also, die nächsten Tage muss ich nochmal alle Logs durchgehen. … Ich habe ja den Eindruck, dass es sich um eine vollgelaufene Tabelle handelt – was allerdings nicht erklärt, warum es _nach_ dem Reboot nicht _sofort_ wieder ging.

Ich bin auch schwer am überlegen, ob ich nicht noch einen zweiten Server ins Netz stelle (Housing FFM), auf dem dann vor allem Nagios laufen wird. Mal darüber nachdenken …

Ich stelle fest…

Denny — Fri, 08 Feb 2008 13:00:38 +0000

Cluster bauen macht kein Spaß. Allein wie unterschiedlich schon die Ansätze und Umsetzungen letzten Endes sind, kann einen ganz schön verwirren.
Durch das Lesen der Doku, versteht meiner einer allerdings mehr und mehr, wo was gebraucht wird. Im Falle meines Planes, Xen Hoch verfügbar zu »konstruieren«, stellen sich da diverse Probleme. Zum einen müssen alle Dom0 Rechner auf den gleichen Storage Poolzugreifen können, und zwar sowohl lesen, als auch schreibend(!). Dies ließe sich z.B. mittels NFS bewerkstelligen, allerdings passen NFS und Geschwindigkeit nicht wirklich zusammen. Des weiteren benötigt es eine Software, die dafür sorgt, dass die nötigen Schritte eingeleitet werden, bei einem Ausfall. Im Falle von Xen bedeutet dies, das ausgefallene DomUs auf anderen Dom0s hochgefahren werden.
ein weiteres Problem besteht im Storage selbst: dieser muss ebenfalls redundant sein. Nun gibt es da eine (an für sich) tolle Software: drbd. Diese Sofware synchronisiert Blockgeräte über ein Netzwerk hinweg. Anders formuliert, wenn sich auf Rechner1 ein Bit ändert, wandert dieses Bit auch auf Rechner 2. Also im Grunde nichts anderes, als ein Spiegel. Das Problem hierbei: nur einer lässt sich zur Laufzeit verwenden. Würde man auf beiden Rechnern diesen Datenträger einhängen (welcher über ein Dateisystem verfügt), würde dieses zielsicher zerlegt werden. Um dem vorzubeugen, unterbindet »drbd« dies, und lässt es nur zu, wenn der Primäre Spiegel nicht verfügbar ist. Wir lernen also, es gibt »primary« und »secondary«.

Das hilft uns allerdings nicht viel, denn wir möchten ja, zeitgleichen Zugriff auf dieses Blockgerät. Nun gibt es ab drbd 8.0.x die Möglichkeit, beide Spiegel auf »primary« zu setzen. Das versetzt uns in die Lage, auf beides Rechnern, diesen Datenträger einzubinden. Die Problematik was das Dateisystem angeht, wurde damit allerdings nicht entschärft, und hier kommt ein Clusterdateisystem zum Einsatz. Dieses regelt den syncronen Zugriff auf ein und die selben Datenstrukturen und verhindert, dass zwei Zugriffe von unterschiedlichen Rechnern, zur selben Zeit auf die selben Daten schreiben und damit ein inkonsistentes Dateisystem produzieren. Und genau hier hänge ich nun schon seit drei Tagen. Soviel zur Theorie.

Mir gelang es zwar, »drbd« aufzusetzen, aber bei dem mounten des Oracle Cluster Filesystems Version 2, gibt es nur eine Fehlermeldung. Dabei spielt es keine Rolle, ob als Linux ein SLES10sp1 werkelt, oder ein Debian Etch. Stellt sich also die Frage: wo liegt das Problem? Was »drbd« und »ocfs« gibt es zu hauf widersprüchliche Aussagen, die sehr an Voodoo grenzen und für meinen Geschmack nichts ist, was ich produktiv einsetzen wollte (nichts desto trotz, gibt es sie). Warte ich mal die Antwort von der »drbd« Mailingliste ab. Eventuelle werde ich daraus schlauer … ansonsten bleibt nur noch ocfs durch »gfs« zu ersetzen, was in der Komplexität noch ein Stück höher liegt …

Update

Von: Florian Haas (LINBIT Information Technologies GmbH)
An: drbd-user@lists.linbit.com

OCFS2 had a bug that prevented it from working correctly with DRBD. That
filesystem bug was fixed by our own Phil Reisner and is included in kernel
version 2.6.21 and up. Etch is on 2.6.18, SLES 10 is on a patched 2.6.16;
I’m not sure whether they backported Phil’s 2.6.21 fix to that.