Notiz: Xen + Hetzner + IPv6 + Routing

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.

Umbau in den nächsten Tage/Wochen

Ich plane in den nächsten Tagen und Wochen meinen Rootserver höchst wahrscheinlich einer kompletten Neuinstallation zu unterziehen. Ich gehe dieses Mal einen komplett neuen Weg und werde vermutlich OpenSolaris als Untergrund verwenden.
Meinen Teilnehmern habe ich immer erzählt, sie müssen Linux nutzen, um zu erfahren, wie Linux funktioniert und da ich an der TU fast nur noch Solaris habe, nutze ich diese Gelegenheit. Natürlich kann man an dieser Stelle einwerfen, dass sich Solaris10 und OpenSolaris in vielen Bereichen stark unterscheiden, aber die Grundsätze dürften dennoch sehr ähnlich sein, wenn nicht gar identisch. Außerdem wollte ich schon immer mal was neues probieren. BSD Varianten wären zwar auch noch da, aber da mangelt es an Interesse.
Es gibt eigentlich nur eine Sache, die mir den Spaß nehmen könnte, und das wäre der Punkt Virtualisierung. Ich will das jetzige Konstrukt in jedem Fall beibehalten, weil es sich bewährt. Mail, Web, Jabber und Build Systeme zu trennen, halte ich noch immer für eine gute Idee, ganz zu schweigen von der Flexibilität bei einem Umzug.

Die andere Sache, die mich noch ein wenig nervös macht, könnte Oracle sein. Ich erlebe derzeit mit, wie viele Probleme innerhalb der paar Wochen schon aufgetreten sind, die eindeutig zur negativen Seite der Fusion zählen.

Jetzt heißt es ersteinmal Vmware aufsetzen und ausgiebig testen.

Nerv …

Man, heute hat es mal zur Abwechslung mal nicht nur eine VM erwischt, nein, die ganze Xen Kiste hat sich heute wieder mal verabschiedet. Der Verdacht kommt auf, dass der neue Kernel von Debian der Schuldige ist, oder die LVM Snapshots sind böse bzw. deren Code …

Web, Jabber und Co laufen wieder ….

Offline heute nacht

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

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

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

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?

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

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 😉 ..)

Veröffentlicht unter Xen | Verschlagwortet mit