XEN Installations-Script Debian/*Ubuntu inkl VGA-Passtrough

[Bunkasan]

Hab das file jetzt 2 mal runtergeladen, beide male einwandfrei?!

Mit dem Bios hab ich mich bisher nicht weiter gespielt, hatte auch keine veranlassung dazu. Habe bisher keinen Unterschied zum direkt geladenen Bios feststellen können. Halte das ganz nach dem Motto "Never touch a running passtrough..."

 

[DragonTEC]

also, ich krieg das ding ums verrecken nicht auf.. weder win-gzip, noch win-zip, noch linux-unzip..

aber um mein unzip mal zu quoten (ich fands süß):

Archive:  Xeninstall.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of Xeninstall.zip or
        Xeninstall.zip.zip, and cannot find Xeninstall.zip.ZIP, period.

In diesem Sinne: Period!

Ach ne, doch nicht, noch mal zum Bios: Guck mal trotzdem mit GPU-Z, ob der dein Graka takt richtig setzt.. ich weiß es nicht mehr hundertprozentig, aber ich glaube, der hat aus den 650MHz meiner kleinen Graka 150 gemacht..

 

[Bunkasan]

Ich schau gleich mal nach wenn der neueste rc7 ausm ofen kommt. Und lad dann auch mal das ganz neue Release mit "Apply custom patch" Funktion rauf.

unzip + period = frau > zickig

 

[Bunkasan]

Also, neuestes release ist verfügbar, hoffentlich nun ohne "period".

Bios: taktet brav von 400 auf 950, keine auffälligkeiten.

 

[DragonTEC]

okay, das script geht nun Supi!

mir sind noch ein paar sachen aufgefallen:

du unterscheidest ja immernoch nicht zwischen make und make install? mach doch einfach hardcoded

$MK -j128 xyz
$MK install xyz



Ach ja, und ich hab gesehen, du patched die unstable auch mit dem xend und vdt patch.. das hat mir zumindest meine version zerschossen, allerdings läuft meine vanilla unstable dafür problemlos.. geht die unstable bei dir inkl. der patches?

 

[Bunkasan]

Doch, die "make install" in der install section laufen nicht mehr über die Variable $MK, die wird nur noch zum kompilieren eingesetzt. Wenn du mal genau hinsiehst wird auf die 4.1 unstable nur noch der VT-d patch angewendet, welchen ich ja auch dringend brauche, denn ohne VT-d kein HVM Passtrough. Und mit dem läuft die 4.1 einwandfrei. Es wird ja auch nur der Abbruchbefehl entfernt sobald der rmrr-dismatch festgestellt wird, sonst weiter nichts geändert.

 

[Romep]

Auf welcher Distribution kann man das hier installieren? Auf Debian 6 geht es nicht. War ne frische installation.

rm extboot.img vapic.o multiboot.o extboot.o linuxboot.raw linuxboot.img vapic.raw vapic.img multiboot.raw extboot.raw multiboot.img linuxboot.o
install -d -m0755 -p "/usr/local/share/doc/qemu"
install -m0644 -p qemu-doc.html  qemu-tech.html "/usr/local/share/doc/qemu"
install -d -m0755 -p "/usr/local/share/man/man1"
install -m0644 -p qemu.1 qemu-img.1 "/usr/local/share/man/man1"
install -d -m0755 -p "/usr/local/share/man/man8"
install -m0644 -p qemu-nbd.8 "/usr/local/share/man/man8"
install -d -m0755 -p "/usr/local/etc/qemu"
install -m0644 -p /usr/src/xen/qemu-kvm-0.13.0/sysconfigs/target/target-x86_64.conf "/usr/local/etc/qemu"
install -d -m0755 -p "/usr/local/bin"
install -m0755 -p -s qemu-nbd qemu-img qemu-io  "/usr/local/bin"
install: cannot set time stamps for `/usr/local/bin/qemu-nbd': No such file or directory
install: cannot set time stamps for `/usr/local/bin/qemu-img': No such file or directory
install: cannot set time stamps for `/usr/local/bin/qemu-io': No such file or directory
make: *** [install] Error 1

****  Installation failed. Aborting package creation.

Cleaning up...OK

 

[Bunkasan]

Läuft normalerweise unter jedem Debian/Ubuntu, ist allerdings etwas veraltet. Hier mal die Kurzfassung ohne Konfiguration, damit hast zumindest auf jeden fall schon mal nen Suse Kernel und Xen 4.0.1 stable drauf. Damit betanken wir unsere Xen-Cloud nodes.

Das Script halt evtl den eigenen Bedürfnissen anpassen.

 

[Romep]

Hm, unter Ubuntu 10.04 Server gehts auch nicht. Script anpassen ist schlecht. Eigentlich war ich froh in debian xen 4 packages zu haben. Aber scheinbar ist selbst das zu alt um damit eine xbmc vm zu nutzen.

../src/.libs/libvirt_driver_qemu.a(libvirt_driver_qemu_la-qemu_driver.o): In function `qemudVPAssociatePortProfiles':
/usr/src/xen/libvirt-0.8.6/src/qemu/qemu_driver.c:11881: undefined reference to `vpAssociatePortProfileId'
/usr/src/xen/libvirt-0.8.6/src/qemu/qemu_driver.c:11898: undefined reference to `vpDisassociatePortProfileId'
collect2: ld returned 1 exit status
make[2]: *** [libvirtd] Error 1
make[2]: Leaving directory `/usr/src/xen/libvirt-0.8.6/daemon'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/usr/src/xen/libvirt-0.8.6/daemon'
make: *** [install-recursive] Error 1

****  Installation failed. Aborting package creation.

 

[trikolon]

sag mal Bunkasan, wenn ich mir dein letztes skript so ansehe, dann sind da ja alle vga patches usw raus geflogen. braucht man die nicht mehr?

habe nämlich das problem, dass meine hvm mit vga nicht sauber herunter fährt und die komplette dom0 dabei abschießt...

gruß

 

[Bunkasan]

Das letzte Script ist nur für Kernel u. Xeninstallation. Und für Xenclouds braucht man keinen VGA-Passtrough. Um das alte Script zu pflegen fehlt mir wegen Arbeit momentan die Zeit.

 

[trikolon]

benutzt ihr den 37er kernel schon als dom0 kernel? dachte da fehlen die backend treiber noch?

 

[Bunkasan]

Ich teste den 37er gerade auf meiner "Spiel-xen" Backend ist schon ne ganze weile drin. Produktiv eingesetzt wird allerdings der 36er.

 

[trikolon]

die sources holst du dir doch über jeremys git repo oder? welchen branch habt ihr da in verwendung? das wäre sehr interessant für mich

 

[Bunkasan]

Nope, kein Jeremys. Is ein angepasster Suse 2.6.36 der noch ein wenig frisiert wurde.

 

[DragonTEC]

benutzt ihr den 37er kernel schon als dom0 kernel? dachte da fehlen die backend treiber noch?

Ich benutz den suse 37er übrigens für mein everyday xen.. läuft prima, auch wenn das booten etwas länger dauert als beim 36er..

 

[trikolon]

habt ihr eigentlich probleme beim herunterfahren des servers? ich lasse meinen nachts von 23:00 bis 6:00 aus. Ansich funktioniert das auch top, allerdings scheint es mir, wenn die HVM Domain läuft, in der die erste grafikkarte steckt, dann gibts böse segfaults beim huerunterfahren und die Kiste schmiert ab. Ähnliche erfahrungen gemacht?

Gruß

 

[DragonTEC]

moment mal.. du fährst deinen server runter obwohl die VMs noch laufen? oO
Überrascht mich wenig, das das evtl gegen den Baum geht..

Wenn ich meine ganzen domUs runtergefahren hab geht der shutdown ohne probleme..

 

[Bunkasan]

Hm, kann beidem nicht beipflichten, Dom0 init 0 -> DomU's fahren brav runter und dann die Dom0.

 

[trikolon]

ein skript fährt bei mir erst die domUs herunter und dann die Dom0. Ich werde das nochmal genauer beobachten. Der Suse 37er Kernel ist aber noch backportet, oder? habt ihr irgendwelche nachteile feststellen können? wie sieht es denn mit powermanagement damit aus? im moment macht das bei mir xen, also nicht die Dom0, würde das dann auch noch funktionieren?