XEN-Dom0 Support in F10 fraglich

Gestern wurde auf der Fedora-devel ML diskutiert, ob F10 nun den Dom0 Support für Xen zurückerhält. Punkt ist, gestern wäre „beta1 freeze“ für F10 gewesen. Der Freeze wird im FESCO Meeting im IRC heute noch zu klären sein.

Das Problem ist, dass Fedora8 das letzte Fedora mit Xen Dom0 Support ist und dieses ja nach Release von F10 als bald seinen „end-of-life“ entgegen fiebert.

Ergo haben wir kein Fedora mehr das Xen selbst booten kann. Auf der Fedora-devel glaubt man daran, dass vor dem Kernel 2.6.28 realistisch nicht damit zu rechnen ist. Hier bei geht es darum, dass die Kernelentwickler eine Schnittstelle zwischen Kernel und egal welcher  (darunter liegender) Virtualisierung eingebaut haben. Diese „paravirtOPS“ genannte Schnittstelle wird in Xen DomU unter F9 und auch F10 benutzt. Problem ist das hier einige Patches für DomU X86_64 Support und dem i386 Dom0 Support beißen. Außerdem müssen einige syscalls bzw. ehemaligen Hypecalls eben auch auf die „paravirtOPS friendly“ Arbeit umgeschrieben werden. Für den DMA-Code ist dies wohl schon geschehen.

Es wurde auf der Fedora-Xen ML auch nicht anders beschrieben, als das es vielleicht nicht erst, aber kurz bevor Linus die Xen Patches einbaut, auch Fedora seinen Dom0 Support zurück erhält. Wohlgemerkt es wird hier derzeit nur über eine i386 Dom0 geredet. Die x86_64 Dom0 Arbeiten sind noch nicht mal angedacht.

update (Day after FESCO):

Also das Meeting ist vorbei hier das IRC-log. Nein ich habe auch nichts über den Beta1 Freeze darin gefunden. 😀

AMD Quad nur für ESX >3.5

Am Donnerstag hat VMWare die „Systems Compatibility Guide“s für ESX 3 und 3.5/3i erneuert. Für mich ist neu, dass es nun getrennte Guides gibt.

Aber um zum Thema zu kommen, es gibt im ESX3 Guide nur Erwähnungen für Opterons der Bezeichnungen 2xx, 8xx, 20xx, 80xx, 22xx, und 82xx. Das heißt nur die Single und <= K9 Dual Cores sind im Moment auf der „freigegeben“ Liste.

Im 3,5/3i Guide sieht ganz minimal anders aus. Der Dells Poweredge 2970 darf schon mit Barcelonas (23xx also dualSockel) ausgerüstet werden. Dies scheint derzeit aber nur für den ESX 3.5 zu gelten, der 3i ist noch nicht für die Super Virtualisierungs CPUs freigegeben.

Normal nimmt man an, dass es ca. 6 Monate bis zum Support von Hardwareherstellern dauert. Wenn man auch mit die Erstveröffentlichung im September 2007 ansetzt, ist das durchaus noch im Plan. Es gab ja schon Ankündigungen, dass die Rechner die schon AMDs 22xx bzw. 82xx unterstützten, schon zum Weihnachtsfest 2007 auch mit Barcelonas verfügbar wären. Aber dann kam der TLB/Stepping Bug.

Normal nimmt man aber auch an, dass Techniken sobald diese im Server verfügbar sind, ein weiteres halbes Jahr später in Betriebssystemen unterstützt werden. Normal wird dazu die Schnittstelle zur Applikation (API/ABI) nicht verändert.  Aber neue Betriebssystem benötigen nochmal 6 Monate bis Applikationen darauf (re-)zertifiziert werden.

Eine Monat nach der allgemeinen Verfügbarkeit ist zumindest die 2 Sockel Version freigegeben. Für mich sieht das doch rekordverdächtig aus, vor allem wenn man bedenkt das VMWare normal etwas hinterher hängt mit Guides, ich erinnere mal an die Sache mit dem RHEL 5.1. Scheint also so, dass die Welt ganz klar auf diese CPUs gewartet hat. Ich fühle, dass es auch Entzugserscheinungen sein könnten.

VMWare Fehlermeldungen

Ich habe versucht folgende Fehlermeldung in j# zu interpretieren:

A file was not found.

Einfach nur geil diese Meldung. Also erster Deutungsversuch:

Benutzer Du ARS.CH!

Zweiter Versuch unter Einbeziehung dessen was ich gerade im Begriff war zu tun (VM starten):

Also ich bin DRS und mir ist es total Wurscht, ob ein Clusterknoten auf dem ESX schon läuft. Nein die gesharede Ressource interessiert mich auch nicht. Wenn die VM an gehen soll dann dort! Und nun gibt Ruhe doofer Admin … ach übrigens, hast du die gesharede Ressource gesehen, ich kann die gerade nicht finden…(was ich nicht seh, kann mir nix tun)

Dritte eher schon Philosophische Deutung:

DRS != KI, also sag dem Dienst haargenau wie bei einem Baby, was es darf und was nicht und schon darfst Du wieder mit im Sandkasten spielen.

HW’08 Tag 6

Ja wie gesagt heute eine Bonusrunde. Wartungsfenster sind was schönes. Man darf Arbeiten ausführen und Kisten mal neustarten die schon seeeehr lange in der Überwachung meckern, dass es Platz benötigen würde. Okay also nicht mit Plattenplatz und Speicher gegeizt auf das die endlich Ruhe geben. Aber ach was bitte soll den das. Gibt es doch tatsächlich 2 Maschinen die sich vernachlässigt fühlen.

I/O Error, Journal crashed, mounting Filesystem read-only…

… oder so ähnlich. Das Ergebnis ist für Linux eher untypisch=> reboot.

Also ist der Beweis erbracht auch RHEL5 hat Probleme mit dem eigenen SCSI Treiber unter VI 3.0.2. Das schreit nach Nacharbeiten.

Geschützt: Client Virtuallisierung

Dieser Inhalt ist passwortgeschützt. Um ihn anzuschauen, gib dein Passwort bitte unten ein:

Passwort: