xen 3.0 l64 Sarge

[hega72]

Hi,

hat schon jemand xen 3.0 auf nem l64 zum laufen bekommen ?
Ich habs bisher unter sarge vergeblich versucht.
Der Xen Kernel bootet nicht.
Liegt das am Fehlen eines Treibers, um /dev/md1 anzusprechen ?

Wäre klasse, wenn jemand einen Tip hätte

Besten Dank im Vorraus

[mattiass]

hat schon jemand xen 3.0 auf nem l64 zum laufen bekommen ?
Ich habs bisher unter sarge vergeblich versucht.
Der Xen Kernel bootet nicht.

Welchen Xen hast Du verwendet? 3.0 ist recht wanzig. Du solltest 3.0.2-x aus dem Mercurial auschecken. Da kommt auch ein recht aktueller 2.6.16.x mit.

Da ich öfters Probleme mit Initrds für Xen-Kernel hatte, habe ich für Domain 0 einen Kernel gebaut, der alle für den Zugriff auf die Boot-Partition benötigten Treiber statisch enthält. Die Vorgehensweise steht im README.

[hega72]

ja, initrd hat bei mir auch nicht geklappt.
Na,dann versuch ischs mal statisch.
Danke für den Tip mit der Readme ;-)

[wirtsi]

mit depmod -v 2.6.18-xen kann die modules.dep Datei erstellt werden, dann klappts auch mit den Ramdisk-Modulen des XEN Kernels.

Hab mich dann aber wieder davon verabschiedet, will doch lieber den Standardkernel laufen haben ...

Wirtsi

[hega72]

besten Dank soweit. Xen bootet jetzt ( mit initrd hats doch noch geklappt )
jetzt hängts daran, daß er die xfs Partitionen nicht mountet.
/ ist ext3 und kommt hoch - aber der komplette Rest fehlt.

Code: Select all

 uname -a
Linux s15215945 2.6.16-xen #1 SMP Thu Apr 13 18:46:07 BST 2006 i686 GNU/Linux

Code: Select all

mount -a
XFS: SB read failed
mount: /dev/md5: can't read superblock
XFS: SB read failed
mount: /dev/md6: can't read superblock
XFS: unknown mount option [usrquota].
mount: wrong fs type, bad option, bad superblock on /dev/md7,
       missing codepage or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Code: Select all

 cat /etc/fstab
/dev/md1        /               ext3    defaults        1 1
/dev/sda2       none            swap    sw
/dev/sdb2       none            swap    sw
/dev/md5    /usr        xfs     defaults        0 2
/dev/md6    /var        xfs     defaults        0 2
/dev/md7        /home           xfs     defaults,usrquota       0 2
devpts          /dev/pts        devpts  gid=5,mode=620  0 0
none            /proc           proc    defaults        0 0
none            /tmp    tmpfs   defaults        0 0

Code: Select all

cat /etc/mkinitrd/modules

ext3
raid1
md_mod
sata_sis
libata
scsi_transport_sas
sd_mod
scsi_mod
sg
3w-9xxx
3w-xxxx
aacraid
r8169
xfs

[mattiass]

besten Dank soweit. Xen bootet jetzt ( mit initrd hats doch noch geklappt )
jetzt hängts daran, daß er die xfs Partitionen nicht mountet.
/ ist ext3 und kommt hoch - aber der komplette Rest fehlt.

Code: Select all

 uname -a
Linux s15215945 2.6.16-xen #1 SMP Thu Apr 13 18:46:07 BST 2006 i686 GNU/Linux

Schonmal den 2.6.16.13-xen aus dem Mercurial-Repository probiert? Da treten einige Probleme weniger auf:

http://xenbits.xensource.com/xen-3.0-testing.hg

oder (nur Kernel):

http://xenbits.xensource.com/linux-2.6-xen.hg

Kleiner Nachtrag:

Vor ein paar Tagen kam auch Xen-3.0.2-3 mit und Updates zu den Management-Tools. Das bislang häufig auftretende Problem, dass keine Domains mit als 'file:' definierten Images gestartet werden konnten (stattdessen war 'phy' und das Anlegen einen Loop-Devices nötig), scheint jetzt behoben.

Einfach

hg clone http://xenbits.xensource.com/xen-3.0-testing.hg

und dann neu kompilieren...

[hega72]

ich hatte gehofft, daß es nicht wirklich mit Xen zu tun hat, sondern irgendwas mit dem Raid.
Daß vielleicht md5/6/7 nicht gestartet werden... oder so

[mattiass]

ich hatte gehofft, daß es nicht wirklich mit Xen zu tun hat, sondern irgendwas mit dem Raid.
Daß vielleicht md5/6/7 nicht gestartet werden... oder so

Mist, ich hätte genauer hinschauen sollen. Da stehen ja mdX, nicht hdaX... Ich würde dennoch erstmal auf den frischesten Xen und Kernel gehen.

Nachtrag:

Was passiert eigentlich, wenn Du folgendes machst

Code: Select all

dd if=/dev/md5 of=/dev/null count=50 bs=1024

Erhältst Du eine Fehlermeldung, sind die Devices md5/6/7 das Problem. Erhältst Du keine Fehlermeldung, ist das Kernelmodul für XFS schuld...

[hega72]

hmm

Code: Select all

dd if=/dev/md5 of=/dev/null count=50 bs=1024
0+0 records in
0+0 records out
0 bytes transferred in 0.000070 seconds (0 bytes/sec)

was meinst Du ?

[mattiass]

was meinst Du ?

Sieht aus, als würden md5 und Co. gar nicht initialisiert...

[hega72]

ahja - jetzt gehts soweit
Normalen Kernel gebootet und

Code: Select all

cd /etc/mdadm
echo "DEVICE partitions" > mdadm.conf
$ mdadm --detail --scan >> mdadm.conf

dann Xen gebootet und - geht

Danke nochmal für die Tips

[thorsten]

Kann ich mal Details zu deinem Setup erfahren?
Welche physikalischen Platten hast du, welche Partitionen hast du dom0 zugewiesen und welche der/den domU(s)?

Ich habe einige Tests gemacht und festgestellt, dass das backend 'file:' grottenlangsam ist.
bei meiner Maschine hat mir hdparm lesend 22 MB/sec attestiert. Jetzt mappe ich mdX nach sdX per 'phy:' durch und erreiche gute 45 MB/sec.

Also im dom0 die beiden SCSI Platten als Raid1 aufgesetzt:
/dev/md0 -> dom0 Xen (/) md0
/dev/md1 -> domU Host1 sda1 (swap)
/dev/md2 -> domU Host1 sda2 (/)
/dev/md3 -> domU Host1 sda3 (/tmp)
/dev/md4 -> domU Host1 sda4 (/home)
/dev/md5 -> domU Host2 sda1 (swap)
/dev/md6 -> domU Host2 sda2 (/)
/dev/md7 -> domU Host2 sda3 (/tmp)
/dev/md8 -> domU Host2 sda4 (/home)

XEN ist toll, mit dem Setup kann ich auch mit einer GRML CD ohne Probleme in die 3 System chrooten. Die Daten sind also jederzeit im Zugriff :)

Wie sieht es bei euch aus, was für Erfahrungen habt ihr gemacht?

[hega72]

Da bist Du deutlich weiter als ich.
ich bin gerade dabei, die erste domU offline zu konfigurieren und traue mich noch nicht, xend zu starten, da dann mein mich Provider vom Switch abklemmt, wenn die 'fremden' Mac Addressen am Switchport ankommen.

Muß da wohl irgendwas mit ebtables und snat machen.
( falls Du da nen Tip hast )

ich verwende auch erstmal files als backend.

Wenn ich eine domU online habe, berichte ich gerne

[mattiass]

bei meiner Maschine hat mir hdparm lesend 22 MB/sec attestiert. Jetzt mappe ich mdX nach sdX per 'phy:' durch und erreiche gute 45 MB/sec.

[...]

Wie sieht es bei euch aus, was für Erfahrungen habt ihr gemacht?

Genau diese! Mit 'phy:' zu mappen ist weit flotter, egal ob RAID oder flache Partitionen. Dummerweise haben einige Versionen der xen-tools eh Ärger mit 'file:', so dass dann der Weg über ein /dev/loopX nötig ist...

Apropos Xen, hier liegt ein frisches Ubuntu-Dapper-Drake-Image:

http://cdprojekte.mattiasschlenker.de/P ... en-Images/

Apropos: man hat mir ein Vanderpool-Testsystem in Aussicht gestellt. Damit werde ich endlich Xen mit Windows-domUs testen können...

[thorsten]

Muß da wohl irgendwas mit ebtables und snat machen.
( falls Du da nen Tip hast )

Nein sorry, ich habe diesen XEN-Server vor mir in einem eigenen Subnetz mit 30 offz. IPs stehen. Da brauche ich solche ebtables-Sauereien nicht :lol: 8)

[thorsten]

bei meiner Maschine hat mir hdparm lesend 22 MB/sec attestiert. Jetzt mappe ich mdX nach sdX per 'phy:' durch und erreiche gute 45 MB/sec.

[...]

Wie sieht es bei euch aus, was für Erfahrungen habt ihr gemacht?

Genau diese! Mit 'phy:' zu mappen ist weit flotter, egal ob RAID oder flache Partitionen. Dummerweise haben einige Versionen der xen-tools eh Ärger mit 'file:', so dass dann der Weg über ein /dev/loopX nötig ist...

Über loop hört sich das ja noch mieser an (von der Prformanceseite). Ich denke auch dass sich unsere Lösung bewähren wird.

Apropos Xen, hier liegt ein frisches Ubuntu-Dapper-Drake-Image:

http://cdprojekte.mattiasschlenker.de/P ... en-Images/

Apropos: man hat mir ein Vanderpool-Testsystem in Aussicht gestellt. Damit werde ich endlich Xen mit Windows-domUs testen können...

Nice :) Ich werde Anfang nächsten Jahres zuschlagen und mir eine Pacifica Maschine kaufen. Dann gibts zu Hause nur noch eine physikalische Hardware auf dem die einzelnen Maschinen (Workstation/Router/Fileserver) dann laufen.

[mattiass]

Ich denke auch dass sich unsere Lösung bewähren wird.

Kommt drauf an. Mit 'file:' lässt sich eine domU natürlich leichter umziehen als mit direktem Mapping, das ist in vielen Fällen wichtiger als das letzte Bißchen I/O-Performance.

Nice :) Ich werde Anfang nächsten Jahres zuschlagen und mir eine Pacifica Maschine kaufen. Dann gibts zu Hause nur noch eine physikalische Hardware auf dem die einzelnen Maschinen (Workstation/Router/Fileserver) dann laufen.

So ähnlich habe ich das auch vorgesehen... Zumindest meine Testrechner werden konsolidiert werden.

[thorsten]

Ich denke auch dass sich unsere Lösung bewähren wird.

Kommt drauf an. Mit 'file:' lässt sich eine domU natürlich leichter umziehen als mit direktem Mapping, das ist in vielen Fällen wichtiger als das letzte Bißchen I/O-Performance.

Naja 22MB/sec zu 45 MB/sec finde ich schon nicht ohne. Dabei lief sonst nichts auf dem host. Je nachdem was du genau auf der Maschine machst (fileserver oder nur statischer Webserver; 100MBit oder Gigabit LAN), kann das schon einen beträchtlichen Unterschied machen.

Zum Punkt Umziehen habe ich eine Idee: http://www.drbd.org/
Leider habe ich das noch überhaupt nicht weiterverfolgt aber ich stelle mir das so vor:
Wenn die Hardwarearbeiten anstehen, aktiviere ich ein Raid1 über drbd, dumpe den Speicher in ein file, kopiere das auf die andere Maschine (XEN unterstützt das ja) und starte den Server auf der 2. Hardware.
Könnte klappen, oder?! :)

[mattiass]

Naja 22MB/sec zu 45 MB/sec finde ich schon nicht ohne. Dabei lief sonst nichts auf dem host. Je nachdem was du genau auf der Maschine machst (fileserver oder nur statischer Webserver; 100MBit oder Gigabit LAN), kann das schon einen beträchtlichen Unterschied machen.

Es kommt drauf an. Bei vielen Webservern dürfte die Festplatte wniger der Flaschenhals sein.

Zum Punkt Umziehen habe ich eine Idee: http://www.drbd.org/
Leider habe ich das noch überhaupt nicht weiterverfolgt aber ich stelle mir das so vor:
Wenn die Hardwarearbeiten anstehen, aktiviere ich ein Raid1 über drbd, dumpe den Speicher in ein file, kopiere das auf die andere Maschine (XEN unterstützt das ja) und starte den Server auf der 2. Hardware.
Könnte klappen, oder?! :)

Wenn die domU direkt auf den Network-Block-Devices oder NFS arbeiten kann, funktioniert die Live-Migration mit den Xen beiliegenden Tools in Sekundenbruchteilen, also ohne spürbare Downtime. Der Nutzer denk nur, da hätte jemand kurz das Netzwerkkabel herausgezogen und wieder reingesteckt.

Bei der erforderlichen Initrd für den Boot von DRDB bin ich bereit, mitzuarbeiten...

[thorsten]

Wenn die domU direkt auf den Network-Block-Devices oder NFS arbeiten kann, funktioniert die Live-Migration mit den Xen beiliegenden Tools in Sekundenbruchteilen, also ohne spürbare Downtime. Der Nutzer denk nur, da hätte jemand kurz das Netzwerkkabel herausgezogen und wieder reingesteckt.

Richtig - so habe ich es auch gelesen aber noch nicht gesehen/getestet.
Da kam mir dann auch die Idee mit drdb

Bei der erforderlichen Initrd für den Boot von DRDB bin ich bereit, mitzuarbeiten...

Gerne, bei mir wird das aber erst in den Sommerferien ruhiger, da habe ich dann 3 Wochen Urlaub.