ctserver.org

wollte ich heute machen, aber bei mir (gentoo 64) baut stubdom nicht. bricht immer mit einen newlib fehler ab. unter archlinux zb geths seltsamerweise..

Ich habe meine Win7 Domain (von XEN 3.4.2 kopiert, dort ist es eine stubdom-dm) zum Laufen bekommen, aber als stub-dom gehts mit XEN 4.0 noch nicht. Die startet zwar anscheinend, aber windows startet nicht und wartet auf goddot ... mit der qemu-dm geht's prima, mit stubdom-dm nicht.

Hallo,
ich habe nun Xen 4.0 unter debian 64 (single core) mit powernow-k8 zum laufen gebracht. weiss jemand warum das mit gentoo und dualcore nicht geht? ist da ein unterschied zwischen single und dualcore?

gruß

Hat denn jemand von euch schon erfolg mit xen 4 gehabt?
ich habe zur zeit 2 probleme:
1. cpufreq funktioniert gar nicht. egal mit welcher xen version. mit meinem singlcore system hat es funktioniert
2. sobald ich ein interface in meine domu config setze, startet diese nicht mehr. ich verwende ein bridged setup, wo ich die bridges im host erstelle.

geht es jemanden da ähnlich oder nur mir so?

gruß

neobiker hat geschrieben:Ich habe meine Win7 Domain (von XEN 3.4.2 kopiert, dort ist es eine stubdom-dm) zum Laufen bekommen, aber als stub-dom gehts mit XEN 4.0 noch nicht. Die startet zwar anscheinend, aber windows startet nicht und wartet auf goddot ... mit der qemu-dm geht's prima, mit stubdom-dm nicht.

Ich sollte mal meine eigene Sig lesen - kaum macht man es richtig, schon geht's

Aus dem README.stubdom (angepasst auf Debian):

Code: Alles auswählen

mkdir -p /exports/usr/share/xen/qemu
ln -s /usr/share/xen/qemu/keymaps /exports/usr/share/xen/qemu
mkdir -p /exports/var/lib
ln -s /usr/lib/xen /exports/var/lib
/usr/sbin/fs-backend &


Hat schon jemand unter Xen 4.0 PCI Geräte in eine pv-domu bekommen oder eine 32 bit pv domu erstellen können?
Also ich habe mit debootstrap eine 64bit pv domu hinbekommen.
Kernel ist 2.6.31.13 dom0 ist Debian.
Problem is allerdings das ich in der domu keine module habe, sprich lsmod bleibt leer.
Es wird auch beim booten gemosert das

Code: Alles auswählen

lib/modules/kernel/modules.deb

nicht da wäre, es ist aber da.
Ich bin da etwas ratlos wie ich mitlerweile.
lspci bleibt logischerweise somit auch leer obwohl mir :

Code: Alles auswählen

xm pci-list 8
domain bus  slot func
0x0000 0x01 0x06 0x0
0x0000 0x01 0x07 0x0
0x0000 0x03 0x00 0x0


In der dom0 angezeigt wird.-

Moin,

pvops Domus laufen nur unter pvops Dom0s.

Außerdem musst Du natürlich ein depmod -a machen, das erzeugt auch
die Datei, die angemeckert wird. Aber eine Ramdisk hast Du doch sicher
auch erzeugt? UNd da macht man auch vorher ein depmod -a...

GrC.

Ich beschreibe mal wie ich es gemacht habe.
Vielleicht findet sich da ja der Fehler eher.

- ein lvm volumen erzeugt, mit ext3 formatiert und eingehängt
- deebootstrap --arch amd64 lenny /mountpoint \eindebianmirror/debian
- aus der dom0 denn mit make dist erzeugten ordner reinkopiert
- chroot /mnt /bin/bash
- mount proc /proc
- einige tools nachinstalliert <grub,ssh python-xml,udev,bridge-utils,bootcd-mkinitramfs
- hostname resolve apt ftsab usw. eingepasst menu.lst erzeugt
- in dist gewechselt und ./install.sh aufgerufen
- depmod -a
- mkinitramfs -o initrd.img-2.6.31.13
- update-grub
- die config der domu erstellt und durchgestartet.

pvops Domus laufen nur unter pvops Dom0s.

Deswegen war ich ja der Meinung das der Kernel aus der Dom0 der richtige sein müsste.
Die Datei ist ja auch vorhanden.

Ich kann mich mit der Maschiene ja auch verbinden per ssh.

Für die 32bit version war ich somit der meinung das der pvops kernel einer 32bit installation sich genauso einbringen lassen müsste.
Da ist allerdings "Bootloader didn't return any data".

Das Xen Kochbuch und Xen 3.2 von Franzis bringen mich diesbezüglich nicht weiter.

Robert

Moin,

also, nun bin ich verwirrt.

Also: Dom0 ist 64 Bit und selbst kompiliert aus Xen 4.0, also ein 2.6.31er.
Nach dem ./install.sh sollte in /lib/modules ein /lib/modules/2.6.31... stehen
und in /boot die vmlinuz-2.6.31.

Dann depmod -a, update-initramfs -c (bzw. -u) -k 2.6.31... und nun steht
in /boot auch noch ein initrd-2.6.31...

In der Configdatei dann auf diesen Kernel und diese initrd referenzieren.
Ich bin der Meinung, dass ich letztens darauf hingewiesen wurde, dass
pvgrub im Moment noch nicht klappt.

Bei 32 Bit auf 64 Bit musst Du den Kernel in eienr 32 Bit Umgebung
übersetzen und installieren. Dann das gleiche machen und die vmlinuz,
initrd, sowie /lib/modules/2.6.31 "ernten" und in die Dom0 kopieren.
Dann die Config dahin umbiegen.

Ansonsten noch dieser Link zur weiteren Hilfe.

Oder der.

Ganz allgemein musst Du natürlich die PCI back- und frontend Treiber
mit übersetzen. Der Inhalt Deiner Config ist entscheidend. Auf der
zweiten Wiki Page findest Du funkionierende Configs.

Ganz allgemein sind die Links hier alle recht lesenswert.

GrC.

Moin,

gerade noch gelesen:

Ich kann mich mit der Maschiene ja auch verbinden per ssh.

Also läuft die DomU? Hast Du mal ein lspci gemacht? Evtl. mit einem
apt-get install pciutils installieren.

Dann weißt Du, ob die PCI devices reingereich wurden.

Bechate außerdem, dass beim Booten der Dom0 die PCI Devices
versteckt werden müssen und sich die Syntax geändert hat.

Statt pciback.hide also xen-pciback.hide etc., siehe Links oben.

GrC.

Ja lspci zeigt ja nichts an.

Die hardware die reingereicht wird kann man auch sehen (aus der dom0)
xm pci-list <DomID>

Die Ramdisk übergebe ich mit
initrd="/boot/initrd.img-2.6.31.13"

Ich schreibe die schritte mal genau auf von Leerer platte bis dahin wo ich jetzt bin.

Robert

modprobe: FATAL: Could not load /lib/modules/2.6.31.13/modules.dep: No such file or directory

Keine chance auch wenn ich mich an die vorgaben deines linkes halte.
Der Hauseigene IPFire pv kernel aus der CT version geht als 32 bit domu kernel mit pci durchreichen nach neuer syntaxregel.

ein paar Ideen die mir dazu gekommen sind:
* hast du in der DomU das Verzeichnis: /lib/modules/2.6.31.13/
* wenn ja, dann führe in der DomU doch depmod -a aus
* was sagt dir denn in der Dom0 lspci -vv | grep pciback

Gruß Ben

Hi Carsten,
ich glaub Dir ja fast alles, aber das hat mich doch verwirrt, weil ich mir das gemerkt hatte (ohne selbst darüber nachzudenken, soll man einfach nicht tun )

Carsten hat geschrieben:Moin,

pvops Domus laufen nur unter pvops Dom0s.

GrC.

Ich habe eben mit meinem XEN 3.4.2 und normalem Dom0 XenLinux Kernel 2.6.18 den originalen EFW 2.4 PAE Kernel in der EFW 2.4 DomU installiert und erfolgreich gestartet. Läuft mit der Änderung, den Ram auf mind. 900MB zu setzen (mit 768MB bootete die tatsächlich nicht!). Freilich ohne PCI Devices in die EFW reinzureichen.

Moin neo,

Freilich ohne PCI Devices in die EFW reinzureichen.

Das galt im Kontext PCI passthrough, das habe ich aber nicht ausreichend
deutlich gemacht.

Ich habe auch diverse 2.6.32er pvops Kernel unter einer 2.6.18er Dom0
laufen, aber nur ohne PCI passthrough.

Ich habe nunmehr ein Testsystem auf Basis P4 mit Xen 4.0.1-rc-irgendwas
und 2.6.32.15er pv_ops Kernel und mache Tests mit:

- SiS onboard NIC
- e100 NIC
- Technisat SkyStar2 DVB-S

und nur die SiS geht. Ich debugge gerade ein wenig mit meinem Kumpel
Konrad von Oracle... (angeb!, angeb!).

Es beschleicht mich das Gefühl, dass das PCI passthrough nicht sauber
geht.

GrC.

Also, PCIpassthrough geht bei mir, aber VDR braucht bei XEN 4.0.0 bei mir 34% CPU, während ich aktuell unter XEN 3.4.2 nur 5% habe. Kann natürlich sein, dass da noch irgendwelche DEBUG Optionen im Kernel sind, aber insgesamt bin ich weder mit XEN 3.4.3 noch mit XEN 4.0 glücklich...lauter Fehler, ob bei PVUSB oder dem xm Kommando... nervig.

XEN 3.4.2 ist aktuell definitv die beste Wahl für Produktivsysteme, da geht sogar PVUSB genauso performant wir PCIpassthrough bei mir, aber vor allem geht einfach alles richtig. Der XEN 3.4.3 Hypervisor läuft auch mit den XEN 3.4.2 Kernel und Xen-Tools, aber da kann ich wohl besser komplett bei XEN 3.4.2 bleiben (anstatt dem Mix).

Ab XEN 4.0.2 kann man dann nochmal testen, wobei ich zum Glück bei meiner Hardware bei 3.4 bleiben kann, da ich definitiv keinen Kernel >= 2.6.31.x in der Dom0 brauche und somit von XEN 4 keine Vorteile zu erwarten habe. Hat schon seinen Grund, dass der aktuelle Xenserver auch bei 3.4.2 bleibt...einzig die VUSB Option im xend Konfigfile würde mich bei XEN 4 reizen, aber da läuft mein pvusb skript unter XEN 3.4.2 perfekt, so auch da kein Bedarf.

Also insgesamt hat sich mal wieder bewahrheitet: Never change a (perfect) running system!