Xen und 3D

[DragonTEC]

ja, vielleicht habt ihr ja recht.. gut, dann kommt die hier wohl auf meinen einkaufszettel:

Test: Sapphire Radeon HD 5450 - 04.02.2010 - ComputerBase

hat sogar eyefinity und DX11!! is mir besonders wichtig bei ner passivgekühlten Karte ohne Stromverbrauch

 

[DerKlops0r]

Ich habe noch eine Idee für Desktop-Wiedergabe von einer Windows VM:
anstelle von VNC einfach VLC benutzen

Per VLC Server den Desktop (screen://) als Video/Audio-Stream wiedergeben, lokal oder über Kabel-Netzwerk sollte das möglich sein bzw. bandbreitenmäßig ausreichen, natürlich kommt dann ein horrender Mehraufwand hinzu zum Encoden

mh, man benötigt definitiv noch 2te Tastatur+Maus oder irgendwie andere Lösung zum User Input (parallel VNC? oh man! )

Aber Video-Stream sollte zumindest besser funktionieren als VNC für "flüssige" Wiedergabe von Desktop-Inhalten (Spiele/Video/etc.), sofern die Leistung des Systems stimmt!!

kA ob das wirklich hilft, ist nur so eine Spinnerei gerade von mir

Gruß

ps. User Input könnte auch direkt über VLC möglich sein, ich glaub sowas wie ein VNC modul ist in VLC schon drin
pps. oh man VNC, VLC... MEHR ähnliche abkürzungen!!!!!!!!!!

 

[Bunkasan]

Falls du deinen Schreibtisch nicht mit Eingabegeräten überfluten willst, würde ich dir meine Lösung empfehlen, einen Controller in der Dom0 belassen, um im Zweifelsfall immer noch eine physische Verbindung für einen Hardreset der DomU´s zu haben, den zweiten Controller kannst du dann ja bequem per script von einer DomU zu nächsten weiterreichen, hotplugging macht bei allen von mir getesteten Komponenten (Sound (Onboard u Pci-e), Grafik, Ob-Lan, Firewire, USB) keine schwierigkeiten, ausser der Graka und einem zickigen Raidcontroller.

Edit: Um es noch ein wenig zu präzisieren, PS2 Passtrough ist per Patch zusätzlich zur Graka möglich, werden aber die wenigsten noch haben, USB-Passtrough gibts in 3 varianten, einmal den ursprüngliche, der nur klägliches 1.1 bietet, bei mir mit den wenigsten Geräten klappen wollte, PVUSB Support, den es bisher nur in den alten XenLinux kernels 2.6.18 u 2.6.26 gibt, und noch nicht in dem aktuellen PVOPS Kernel portiert wurde, und letztlich die somit für mich einzig praktikable Lösung des kompletten durchreichens eines Controllers.

 

[DragonTEC]

bahahha, wie geil, du hast mir grad den threat beantwortet: http://extreme.pcgameshardware.de/h...-ue/112830-tv-als-zweitmonitor-ueber-lan.html

dieses "screen://" hab ich einfach nicht gefunden..

dann kann ich ja meinen server vom TV aus steuern und mein tv vom server aus.. abstruse technik welt

 

[DerKlops0r]

gern geschehen, hab auch gleich mal als quasi-fast-stief-Vater des Gedanken reingepostet
mir grauts aber ein wenig vor der nötigen Performance dafür

 

[DragonTEC]

So, auf Bunkasans wunsch geht die Diskusion jetzt hier weiter..

Hi DragonTEC,

momentan bastel ich mit den Kernels von Jeremy rum, deshalb auch das git im code, ist nur als repository verfügbar, und dem SLES 11, der allerdings etwas angepasst werden muss um auf nem Debian kompiliert werden zu können. Beide haben die Xenpatches bereits dabei. Die VGA Passtrough patches hab ich mir von allen möglichen Seiten und Newsgroups zusammengesucht, und im secvga.patch zusammengefasst, genaue Quellenangaben werden da schwierig. Ich lad nochmal die neuste Version meines Scriptes hoch, da sind auch die Quellen für die Kernels drin (im File Downloadsources). Die Xenpatches auf nem .34 oder .35 anzuwenden sollte schwierig werden, da sie dazu portiert werden müssten. BTW, vielleicht sollten wir die Kommunikation im Thread weiterführen, damit auch andere was davon haben.

Hi Bunkasan,

ich hab jetzt auch mit meinem Xen / VGA Passthrough projet begonnen und mir noch mal dein script geschnappt.. echt gute arbeit.. allerdings blick ich da nicht so recht durch.. was ich zB nicht gefunden hab ist, wo du die patches her hattest, um den kernel zu patchen? oder was hast du da genau gemacht? Deine Variablennamen sind leider etwas unübersichtlich, sodass ich nicht immer genau nachvollziehen kann, was du wo herholst..

1) Wo nimmst du denn den kernel her? ausm xen, kernel.org oder deb?
2) wo hast du die patches her? (zB vdt.patch oder secvga.patch)

Da ich mir gern n xen kernel für 2.6.34 oder 35 zusammenschrauben würde, bin ich halt grad auf der suche nach patches und literatur..

Das klingt schon mal prima.. den patch hätte ich natürlich gern

so wie ich das sehe hab ihc unter debian momentan ein paar möglichkeiten.. korrigiert mich, wenn ich mich irre..

1) 2.6.32er kernel aus dem deb experimental release, wie hier beschrieben: Xen - Debian Wiki

hätte den vorteil das man nicht selbst kompilen muss und es is ein paravirt_ops kernel

2) 2.6.32er Kernel selber backen auf basis von jeremys release auf kernel.org.. kurze anleitung hier: Das Rootserver-Experiment Blog Archive Installation von Xen 4.0.1 mit pvops-Dom0 auf Ubuntu 10.04 ist zwar für ubuntu, aber sollte in etwa genau so gehen..

3) 2.6.34er Kernel selber backen mit suse backport patches.. anleitung in etwa hier: Das Rootserver-Experiment Blog Archive Ein Tag mit Xen: Vanilla-Xen und -Kernel auf Ubuntu Karmic installieren , nur mit dem 2.6.34er kernel und dem patch von da: Downloads - gentoo-xen-kernel - Project Hosting on Google Code

4) 2.6.35er Kernel selber backen.. angeblich sind da wohl relativ wenig patches nötig und der 35er kommt ja auch mit ein paar neuen virtualisierungsfeatures.. der grobe prozess etwa hier beschrieben: XenParavirtOps - Xen Wiki allerdings hab ich hier gar keine patches gefunden.. kann man da vllt was aus dem 4.0.1er release von xen klauen?

zu beachten bei den entscheidungen is vllt noch das hier: XenKernelFeatures - Xen Wiki

Mein Problem ist jetzt, das ich wohl einen >=2.6.33er kernel brauche, da (wie im anderen threat zu lesen) er ansonsten meine lan karte nicht mag.. blöde teure und viel zu neue mainboards.. ansonsten würde ich wahrscheinlich zum 32er experimental tendieren ( vorschlag 1) )..

irgendwer ideen / anmerkungen?

 

[Bunkasan]

Hat etwas länger gedauert, aber hier die neusete Version des Scriptes.

Hinzugekommen ist neben dem Jeremy's PVOPS Kernel nun auch der Novell SLES 11 PVUSB Kernel.
Desweiter im ZIP zu finden ein configfile (als beispiel) für Windows7 sowie ein Startscript für Windows, welches nachträglich Hardware einbindet, welche noch nicht beim Systemstart vor der Dom0 verborgen wurde.

Leider funktioniert der Secondary VGA Patch nicht mehr bei der Xen 4.1 unstable, da grundlegende Funktionen bezüglich des PCI-Passtrough geändert wurden. Portierung ist in Arbeit.

Edit: Wer lesen kann ist klar im Vorteil. Die Kernels von Kernel.org haben seit dem .26er die Xen-pvops Patches bereits enthalten... hätte mir viel Arbeit erspart. Sollte also für deine Zwecke passen, und erklärt auch deine Frage nach den unauffindbaren Patches. Und die Grundgebühr ist auch schon drin.

Edit3: Soweit ich gerade aus den Sourcen rauslesen kann, ist allerdings nur der Xen-DomU support im Mainstream Kernel. Somit bleiben wohl nur die Gentoo Patches für den .34

Edit2: Da sich leider meine Nvidia-Dom0-karte seit kurzem der Bilddarstellung verweigert, könnte ich nicht weiter an der 3D-beschleunigung mit NV Treibern arbeiten, und sämtliche Patches für den fglrx (Zweitkarte jetzt auch ATI) haben bisher nur in Systemfreezes geendet. N' Fass Bier und +10 Internets für den ders zum laufen bekommt!

 

[DragonTEC]

Woa, ich hab deine edits gar nicht gesehen..

Edit2: Da sich leider meine Nvidia-Dom0-karte seit kurzem der Bilddarstellung verweigert, könnte ich nicht weiter an der 3D-beschleunigung mit NV Treibern arbeiten, und sämtliche Patches für den fglrx (Zweitkarte jetzt auch ATI) haben bisher nur in Systemfreezes geendet. N' Fass Bier und +10 Internets für den ders zum laufen bekommt!

Da glaub ich hab ich was gelesen und vermute zumindest ich weiß, warum deine nvidia nicht mehr will:

Installing Xen on Ubuntu 9.10 | Brandon's Blog

Bereich "Install Xen Kernel Sources" 3. Abschnitt:

Unfortunately, the pv-ops kernel will not work with binary graphics drivers provided by Nvidia. Since I have an Nvidia graphics card (and want to use the binary drivers) I need to use the standard Xen kernel. The standard Xen kernel is still version 2.6.18, however luckily Andrew Lyon maintains forward ported patches for Gentoo that we can use on our Ubuntu install.

also brauchst du wohl n kernel ohne pv-ops, damit die nvidia wieder läuft..


und okay, der 2.6.35er kernel is wohl erstmal gestrichen.. hatte mich verlesen und das is tatsächlich erstmal nur domU.. schade eigentlich.. grade die virtuallisierungs- und energy- optionen klangen grade für n heimserver sehr interessant.. naja, mal gucken wie lange die ports dafür noch brauchen..

ich kauf mir morgen ne pci lan karte und bastel mir dann nen 34er kernel mit den suse backports..


€1: Hab vllt noch etwas interessantes gefunden.. jeremy hat seit vorgestern n neues "stable" release von seinem branch: http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00806.html ->
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git xen/master vllt hilft dir das ja ein bisschen weiter bunkasan..

€2: Ich hab grad noch einen Tipp von einem aus der Xen-Mailingliste bekommen: Angeblich ist der 2.6.35er Kernel aus Ubuntu sowohl voll Xen-kompatibel, als auch als .deb paket erhältlich.. wär das eventuell noch ne sehr praktische alternative? die info wundert mich zwar etwas, da 2.6.35 afaik nur domU unterstützt, aber ich werds einfach mal versuchen..

 

[Bunkasan]

Ach, die NV verweigert nicht nur die Bildausgabe sondern jeglichen dienst. Die hats hinter sich. Aber trotzdem danke.

Kleiner Tipp, schnapp dir anstelle der patches gleich den Suse 2.6.34 Kernel
Index of /repositories/Base:/Kernel/standard/src

Wie du den kompiliert bekommst, findest du im Script.

Edit: Hab mir den Kernel gerade mal angesehen, ist genauso ein PVUSB Kernel wie der SLES 11.

Die beiden anderen werd ich mir auch mal zu gemüte führen.

 

[DragonTEC]

so, ich habs jetzt eeeendlich mal geschafft auch ein bissel zu basteln.. bin allerdings noch nicht all zu weit gekommen..

zuerst hab ich mal versucht, den ubuntu 2.6.35er server kernel mit nem xen unstable zu benutzen (ich mag halt n 35er haben ^^ ).. zu meiner überraschung hat das auch FAST geklappt.. kernel (obwohl nicht explizit xen version) startet.. so halb.. nach dem "Scrubbing free RAM" schritt kommt mir dann meine konsole abhanden und irgendwo, ich glaub vor dem "copy kernel to physical ram" schritt hängt er dann.. verhalten is mit 4.0.1 stable genau so wie bei 4.1 unstable..

danach hab ich mal versucht, nen 2.6.34er vanilla kernel mit den gentoo / suse backport patches zu bauen.. da hings aber nach ner halben stunde irgendwo bei irgendwas.. kein bock mehr gehabt.. sein gelassen..

das bunkasan script is auch relativ früh ausgestiegen mit:

...
Statusinformationen werden eingelesen...
E: Paket libxen3-dev kann nicht gefunden werden
E: Paket libxen3 kann nicht gefunden werden

DANN, weil mir irgendwie langweilig war, hab ich mal geguckt was eigentlich im Debian squeeze repo drin is, und siehe da: Da schwirrt ein Xen 4.0 genau so rum wie n fertiger 32er Xen kernel.. alles installiert, läuft.. also aufn ersten blick startet und xm list macht was.. was interessantes wie domUs bauen, vga passthrough oder sonstwas, hab ich noch nciht gemacht.. war für heute glaub ich auch genug..

Was ich mich jetzt aber frage: hat der debian 32er kernel eigentlich irgendwelche nachteile gegenüber den ganzen anderen 32er custom kernel? jeremeys kernel ist ja glaub ich auch nur n 32er kernel, oder?

€1: mein 35er Kernel hängt (habs mit xencons=text-80x60,keep rausgefisch) bei:
Mapping kernel into physical mmory
about to get started...

danach kommen 2 traps.c:2302:d0 Domain attempted WRMSR 00000000000000002ff from 00000000:00000c00 to 000000000:00000000000.

 

[Bunkasan]

Das mag daran liegen, dass der Ubuntu.35er auch nur ein DomU kernel ist. Zumindest der im Ubuntu git repo, und ich habs ehrlich gesagt noch nie probiert nen non-xen-kernel nach dem Hypervisor zu booten, kanns also nicht als Fehlerquelle bestätigen.

Das mit meinem Script liegt daran, das es eben wirklich explizit unter/für Ubuntu gemacht wurde, und sich das paket unter debian einfach anders nennt. Debian -- Package Search Results -- libxen-dev
Müsstest dir, um es zu benutzen, die Arbeit machen, die Pakete aus der downloadlist unter 'tools' anzupassen. Wo es aber dann noch hängen würde, steht in den Sternen, bzw im log.

Mit den patches auf nem vanilla bin ich auch nicht wirklich weit gekommen. Deshalb auch der Vorschlag mit dem Suse .34er, welchen ich grade mit großer Zufriedenheit am laufen habe.

Solltest du allerdings VGA-Passtrough machen wollen, wirst du um den secvga.patch nicht rum kommen, da der ursprüngliche im xen 4.0x vorhandene, soweit ich das rausgelesen habe, auch primary nur mit ein paar Intel-onboard chips läuft, und das hat sich als meine 58er kurzzeitig solo war, auch so bestätigt.

Solltest du nicht auf irgendwelche speziellen Features eines bestimmten Kernels verzichten wollen oder können, sollte es prinzipiell ziemlich egal sein welchen du am laufen hast. PVOPS ist eigentlich nur für domU´s wirklich interessant, PVUSB steigt bei mir sowieso immer beim einbinden des Controllers ins Windows aus, wäre allerdings deine Erfahrung damit interessant, und sonst unterscheidet sich der Xencode in den Kernels nicht allzusehr.

Würd an deiner stelle mal den Suse .34 aus meinem letzten Post versuche, vielleicht klappts dann auch mitm Netzwerk.

 

[DragonTEC]

ja, das der ubuntu kernel wohl nur domU supportet, da bin ich auch grad irgendwie drauf gekommen.. man man man, nicht mal leuten auf der xen mailing liste kann man trauen.. ^^

ich glaub, um zu verstehen, was du mit dem suse kernel gemacht hast, muss ich mir erstmal dein script umschreiben.. das gance xs xc xt geraffel ist nicht wirklcih leserlich.. aber dann wird das mein nächster versuch ^^

 

[Bunkasan]

Bekenne mich der Tippfaulheit für schuldig. Deshalb auch die Pfad-extremabkürzung.

Das essentielle für den Suse ist, das rpm mit "rpm2targz" in ein .tar.gz umzuwandeln, entpacken, die ganzen patches.*.tar-gz zu entpacken, und dann über die series.conf patchen lassen. Dann noch die xen.config aus der config.tar.bz2 entpacken und backe backe kernel...

Das einzige was du dazu ausm script brauchst ist

for f in patches.*.tar.bz2; do tar xfj $f || break; done
for p in $(./guards $(./arch-symbols) < series.conf); do patch -d $ks -p1 < $p || break; done

Der rest ist nur Downloaden, umwandeln, entpacken und aufräumen.

Edit: und zum besseren Verständnis:

xs='/usr/src/xen'
xt=$xs'/tools'
xp=$xt'/patches'
xc=$xt'/config'

kd= das jeweilige kernel-source directory
xd= das jeweilige xen-source directory

 

[DragonTEC]

ja, so ähnlich hatte ich das auch aus dem script gelesen.. wobei ich noch nicht bei rpm2targz war.. wo haste das denn her? das mit den patches hatte ich soweit verstanden, edoch frag ich mich, wo du die series.conf herhast.. die is in deinem targz nicht drin..

 

[Bunkasan]

http://slackware.osuosl.org/slackware_source/a/rpm2tgz/rpm2targz

Das sollte ich wohl noch zu den tools hinzufügen... ganz vergessen...

Die series.conf findet sich im kernel-source

Mal ein kleines howto:

nachdem du das rpm entpackt hast findest du folgende Struktur im Verzeichenis:

drwxr-xr-x  2 root root     4096 2010-09-24 01:52 ./
drwxr-xr-x 12 root root     4096 2010-09-24 01:52 ../
-rwxr-xr-x  1 root root     1092 2010-09-24 01:52 apply-patches*
-rwxr-xr-x  1 root root     1455 2010-09-24 01:52 arch-symbols*
-rwxr-xr-x  1 root root     1711 2010-09-24 01:52 built-in-where*
-rwxr-xr-x  1 root root      436 2010-09-24 01:52 check-for-config-changes*
-rwxr-xr-x  1 root root      775 2010-09-24 01:52 check-supported-list*
-rwxr-xr-x  1 root root     1605 2010-09-24 01:52 compute-PATCHVERSION.sh*
-rw-r--r--  1 root root      129 2010-09-24 01:52 config.addon.tar.bz2
-rw-r--r--  1 root root     1528 2010-09-24 01:52 config.conf
-rw-r--r--  1 root root      238 2010-09-24 01:52 config.sh
-rw-r--r--  1 root root   210917 2010-09-24 01:52 config.tar.bz2
-rwxr-xr-x  1 root root     1351 2010-09-24 01:52 configtool.pl*
-rw-r--r--  1 root root      413 2010-09-24 01:52 devel-post.sh
-rw-r--r--  1 root root      138 2010-09-24 01:52 devel-pre.sh
-rwxr-xr-x  1 root root     3155 2010-09-24 01:52 extract-modaliases*
-rwxr-xr-x  1 root root     1237 2010-09-24 01:52 find-provides*
-rwxr-xr-x  1 root root     1588 2010-09-24 01:52 group-source-files.pl*
-rwxr-xr-x  1 root root     7632 2010-09-24 01:52 guards*
-rwxr-xr-x  1 root root     2661 2010-09-24 01:52 kabi.pl*
-rw-r--r--  1 root root      426 2010-09-24 01:52 kabi.tar.bz2
-rw-r--r--  1 root root    26902 2010-09-24 01:52 kernel-binary.spec.in
-rw-r--r--  1 root root     3239 2010-09-24 01:52 kernel-docs.spec.in
-rw-r--r--  1 root root     2190 2010-09-24 01:52 kernel-module-subpackage
-rw-r--r--  1 root root   819636 2010-09-24 01:52 kernel-source.changes
-rw-r--r--  1 root root      111 2010-09-24 01:52 kernel-source.rpmlintrc
-rw-r--r--  1 root root   625967 2010-09-24 01:52 kernel-source.spec
-rw-r--r--  1 root root     7429 2010-09-24 01:52 kernel-source.spec.in
-rw-r--r--  1 root root      739 2010-09-24 01:52 kernel-spec-macros
-rw-r--r--  1 root root     2122 2010-09-24 01:52 kernel-syms.spec.in
-rw-r--r--  1 root root 67633622 2010-09-24 01:52 linux-2.6.34.tar.bz2
-rw-r--r--  1 root root     2029 2010-09-24 01:52 macros.kernel-source
-rwxr-xr-x  1 root root     7423 2010-09-24 01:52 mkspec*
-rwxr-xr-x  1 root root     3538 2010-09-24 01:52 modversions*
-rw-r--r--  1 root root     1111 2010-09-24 01:52 old-packages.conf
-rw-r--r--  1 root root     3481 2010-09-24 01:52 package-descriptions
-rw-r--r--  1 root root      129 2010-09-24 01:52 patches.addon.tar.bz2
-rw-r--r--  1 root root    49300 2010-09-24 01:52 patches.apparmor.tar.bz2
-rw-r--r--  1 root root    80888 2010-09-24 01:52 patches.arch.tar.bz2
-rw-r--r--  1 root root   132128 2010-09-24 01:52 patches.drivers.tar.bz2
-rw-r--r--  1 root root   121004 2010-09-24 01:52 patches.fixes.tar.bz2
-rw-r--r--  1 root root      129 2010-09-24 01:52 patches.kabi.tar.bz2
-rw-r--r--  1 root root      136 2010-09-24 01:52 patches.kernel.org.tar.bz2
-rw-r--r--  1 root root     3934 2010-09-24 01:52 patches.rpmify.tar.bz2
-rw-r--r--  1 root root      127 2010-09-24 01:52 patches.rt.tar.bz2
-rw-r--r--  1 root root   862176 2010-09-24 01:52 patches.suse.tar.bz2
-rw-r--r--  1 root root    33729 2010-09-24 01:52 patches.trace.tar.bz2
-rw-r--r--  1 root root  1952353 2010-09-24 01:52 patches.xen.tar.bz2
-rw-r--r--  1 root root     2804 2010-09-24 01:52 post.sh
-rw-r--r--  1 root root     1182 2010-09-24 01:52 postun.sh
-rw-r--r--  1 root root      950 2010-09-24 01:52 pre.sh
-rw-r--r--  1 root root      138 2010-09-24 01:52 preun.sh
-rw-r--r--  1 root root      345 2010-09-24 01:52 README.KSYMS
-rw-r--r--  1 root root    15506 2010-09-24 01:52 README.SUSE
-rw-r--r--  1 root root    38401 2010-09-24 01:52 series.conf
-rw-r--r--  1 root root      329 2010-09-24 01:52 source-post.sh
-rw-r--r--  1 root root      107 2010-09-24 01:52 source-timestamp
-rwxr-xr-x  1 root root     2218 2010-09-24 01:52 split-modules*
-rw-r--r--  1 root root   135384 2010-09-24 01:52 supported.conf
-rwxr-xr-x  1 root root    16869 2010-09-24 01:52 symsets.pl*

Das linux-2.6.34.tar.bz2 ist der eigentliche source code, einfach auch entpacken.

dann einfach

for f in patches.*.tar.bz2; do tar xfj $f || break; done
for p in $(./guards $(./arch-symbols) < series.conf); do patch -d   linux-2.6.34 -p1 < $p || break; done

drüber laufen lassen. Damit wird der Sourcecode gepacht.

Dann nur noch die "xen" aus der "config.tar.bz2" als ".config" in das eigentlich Sourceverzeichnis kopiert, und schon kannst du backen.

 

[DragonTEC]

haha, das is aber deutlich länger als das rpm2tgz, was ich grad gefunden hab:

SLUG_Wiki: Rpm2tgz

meins funktioniert auch, allerdings hab ich depp grad den gesamten kernel ins /usr/src verzeichnis ohne unterordner entpackt.. -.- bin dann mal aufräumen.

 

[Bunkasan]

Yeah, deins rockt wirklich. Lässt einfach rpm2cpio die ganze arbeit machen...

 

[DragonTEC]

ah, jetzt hab ich einiges besser gerafft.. vielen dank für die anleitung!

ich dachte immer, dein script bezieht sich auf die sachen in deinem zip, aber davon hast du ja gar nix mehr genommen..

naja, kommt davon, wenn man ließt, ohne vorher mal zu entpacken

so, kernel baut, ich geh pennen und hoffe, morgen vom duft frisch gebackenen kernels geweckt zu werden..

 

[DragonTEC]

so, nun bin ich ne ganze ecke weiter.. (deshalb auch der doppelpost und kein edit für die leute mit abo..)

der kernel (der suse 34er) und xen 4.0.1 stable laufen prima und ne erste debian hvm hab ich auch schon erstellt.. das vnc vorwarding is ja mega geil..

nun hab ich aber noch ein paar baustellen:

1. xen auf LVMs.. irgendwie mag der meine device definitionen in der domU.cfg nicht.. sehen wie folgt aus:

disk = ['phy:XEN_VMs/domU1,sda1,w','phy:XEN_VMs/domU1_swap,sda2,w','phy:/dev/loop0,hda:cdrom,r']
habs auch schon mit nem /dev/ vor der volumegroup versucht, aber das wollte er irgendwie auch net.. natürlich auch schon mit ioemu: vor dem zieldevice und auch mit hda1 statt sda1..

wird alles mit "qemu: ignoring not-understood drive `sda1'" quitiert..

2. bridging
mit den standardmitteln (also die xenbr0) geht das irgendwie nicht.. bridge ist zwar da laut brctl show, aber beim starten der VMs kommt immer ein

Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

also momentan noch vms ohne netz

3. vga passthrough..

hier häng ich momentan noch am hiding der vga vor der dom0.. das 'xen-pciback.hide=(06:00.0)(06:00.1)' nach dem kernel in der grub2 wird scheinbar noch komplett ignoriert..

nun ja, mal gucken, wie es weiter geht.. ich bin vorsichtig optimistisch

 

[Bunkasan]

Bisschen zu spät für dich, aber seit heute ist mein Script auch voll Debian testing funktional... Noch bisschen glattbügeln und ich lads hoch. hab hier auch grad squeeze am laufen.

Zu 1.

'phy:/dev/mapper/blablabla,hda,w',

Zu 2.

Unter xen 4.0 wird die xenbridge eth0 genannt, weshalb auch immer.

Zu 3.

beim Suse 2.6.34 musst du "pciback.hide=" ohne das xen vorne verwenden. Hat mich auch ne weile geärgert.