Xen und 3D
- Ersteller DragonTEC
- Erstellt am
Jo ist mit xen-pciback.hide in grub versteckt und wird auch unter xm pci-list- als mögliches passthrough device gelistet. gfx_passthru habe ich nicht. Hier wurde ja gesagt, dass windows7 das auch so erkennt und ich das lieber ohne machen sollte. Macht allerdings auch keinen unterschied, ob es in der config drin steht oder nicht. Der Fehler tritt bei beiden Varianten auf.
Das Problem ist (vermute ich) der hohe IRQ. Es gibt auf dem System zwei hohe IRQ. Einmal für die bridge NIC und für die Grafikkarte. Der Rest hat einen "normalen" IRQ zwischen 10 und 23. Ich kann wie gesagt den Sata Controller und eine PCIe NIC an VMs durchreichen (haben IRQ 17 bzw. 19).
Das Problem ist (vermute ich) der hohe IRQ. Es gibt auf dem System zwei hohe IRQ. Einmal für die bridge NIC und für die Grafikkarte. Der Rest hat einen "normalen" IRQ zwischen 10 und 23. Ich kann wie gesagt den Sata Controller und eine PCIe NIC an VMs durchreichen (haben IRQ 17 bzw. 19).
nitromaroder
Schraubenverwechsler(in)
Servus Leute,
habe mit grossem Interesse den Thread gelesen, bin ebenfalls dabei meine GraKa zu virtualisieren, habe ein VT-d fähiges Board und zwei Karten, mit welchen ich das probiere - HD4350 und GT220, bleibe jedoch bei schwarzem Bildschirm hängen.
Im moment habe ich FC14 mit Xen (unstable branch, 4.1.0-rc3-pre) und dem 2.6.38-rc2 dom0 Kernel, probiere die Ati Karte durchzuschleifen, nur bleibt mein Bildschirm dunkel.
Bei Xen kompilieren, habe ich, wie vorgeschlagen, mir das BIOS von TechPowerup geholt (Sapphire HD4350, 512MB), es als vgabios-pt.bin ins "tools/firmware/vgabios" gesteckt und Xen komplett gebaut. Ansonsten habe ich keine zusätzliche Patches angewendet, habe ich evnt. was vergessen?
Anbei der Auszug aus dem Logfile:
Viele Grüße,
-NM-
habe mit grossem Interesse den Thread gelesen, bin ebenfalls dabei meine GraKa zu virtualisieren, habe ein VT-d fähiges Board und zwei Karten, mit welchen ich das probiere - HD4350 und GT220, bleibe jedoch bei schwarzem Bildschirm hängen.
Im moment habe ich FC14 mit Xen (unstable branch, 4.1.0-rc3-pre) und dem 2.6.38-rc2 dom0 Kernel, probiere die Ati Karte durchzuschleifen, nur bleibt mein Bildschirm dunkel.
Bei Xen kompilieren, habe ich, wie vorgeschlagen, mir das BIOS von TechPowerup geholt (Sapphire HD4350, 512MB), es als vgabios-pt.bin ins "tools/firmware/vgabios" gesteckt und Xen komplett gebaut. Ansonsten habe ich keine zusätzliche Patches angewendet, habe ich evnt. was vergessen?
Anbei der Auszug aus dem Logfile:
Mich irritiert nur die Meldung hier: "pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x1" - oder kann man das ignorieren?
Viele Grüße,
-NM-
wie machst du denn das durchschleifen? per gfx_passthrough oder ohne?
Wenn du das ohne machst (mit hab ich nie hingerkeigt), musst du die grundinstallation einfach über vnc mach, dann nen grafiktreiber installieren (bei win halt den ati-treiber, bei linux reicht zum anfang auch der fglrx-treiber aus den packages)..
Also im endeffekt (für ne linux domU):
- DomU das erste mal starten und installieren über vnc
- neustart und das erste mal booten, gegebenenfalls neuen kernel inkl. header files installieren (für meine debian files nehm ich immer den 2.6.35er kernel aus den ubuntu packages)
- dann ein aticonfig --initial ausführen, damit ne neue xorg.conf erstellt wird
- neu starten und sich freuen, sobald der monitor angeht und man seinen desktop sieht
Das austauschen des vga bios ist übrigens nicht erforderlich..
Btw: Ich bin überrascht, das bei dir die unstable läuft.. bei mir funktioniert die leider seit ca. 2,5 Monaten nicht mehr.. der build klappt zwar, aber der boot in den dom0 kernel funktioniert bei mir dann nicht sondern es gibt nur n neustart sobald er in runlevel 2 kommt.. hast du da evtl was dran gedreht?
Wenn du das ohne machst (mit hab ich nie hingerkeigt), musst du die grundinstallation einfach über vnc mach, dann nen grafiktreiber installieren (bei win halt den ati-treiber, bei linux reicht zum anfang auch der fglrx-treiber aus den packages)..
Also im endeffekt (für ne linux domU):
- DomU das erste mal starten und installieren über vnc
- neustart und das erste mal booten, gegebenenfalls neuen kernel inkl. header files installieren (für meine debian files nehm ich immer den 2.6.35er kernel aus den ubuntu packages)
- dann ein aticonfig --initial ausführen, damit ne neue xorg.conf erstellt wird
- neu starten und sich freuen, sobald der monitor angeht und man seinen desktop sieht
Das austauschen des vga bios ist übrigens nicht erforderlich..
Btw: Ich bin überrascht, das bei dir die unstable läuft.. bei mir funktioniert die leider seit ca. 2,5 Monaten nicht mehr.. der build klappt zwar, aber der boot in den dom0 kernel funktioniert bei mir dann nicht sondern es gibt nur n neustart sobald er in runlevel 2 kommt.. hast du da evtl was dran gedreht?
B
Bunkasan
Guest
Und falls du es mit (also dem "echten" gfx_passtrough) machen willst, xen 4.0 stable/unstable mit den Patchen von [Xen-devel] GFX Passthrough - Xen Source oder dem zusammengefassten Patch aus meinem Script, und das VGA-Bios, so wie du es schon gemacht hast, mit in die source einkompilieren, dann funktioniert der gfx_passtrough auch mit nicht "Intel IGD" Devices. 
Für die unstable gibt es meines Wissens nach noch keine Secondary-Passtrough Patches. Allerdings hab ich mich aufgrund Zeitmangel und einem einwandfrei laufendem System nicht weiter damit beschäftigt. Was noch zu beachten wäre: Falls du die Patches benutzt, kannst du der DomU nicht mehr als 3GB Speicher zuweisen ohne Crash.
Würde dir allerdings den "Fake-Passtrough" empfehlen, da das ganze, zumindest bei mir, runder läuft.
Für die unstable gibt es meines Wissens nach noch keine Secondary-Passtrough Patches. Allerdings hab ich mich aufgrund Zeitmangel und einem einwandfrei laufendem System nicht weiter damit beschäftigt. Was noch zu beachten wäre: Falls du die Patches benutzt, kannst du der DomU nicht mehr als 3GB Speicher zuweisen ohne Crash.Würde dir allerdings den "Fake-Passtrough" empfehlen, da das ganze, zumindest bei mir, runder läuft.
jup, ich hab mit dem fake-passthrough auch keine probleme.. hab eine domU mit win7 und 2 Monitoren (1. Graka) und eine domU mit Debian wo mein Fernseher über HDMI dran hängt (2. Graka), für n xbmc mediacenter 
€: @Bunkasan: Was mir da grad noch einfällt: Hast du es hingekriegt dein CD-Rom Laufwerk sinnvoll weiterzugeben? über die normale laufwerksgeschichte krieg ich das nicht geöffnet und über die vscsi weitergabe funktioniert das auch nicht..
€: @Bunkasan: Was mir da grad noch einfällt: Hast du es hingekriegt dein CD-Rom Laufwerk sinnvoll weiterzugeben? über die normale laufwerksgeschichte krieg ich das nicht geöffnet und über die vscsi weitergabe funktioniert das auch nicht..
Zuletzt bearbeitet:
nitromaroder
Schraubenverwechsler(in)
Hallo Leute -
das geht ja richtig schnell, mit den Antworten - vielen Dank.
Ok, dann denke ich, weiss ich, wo mein Problem liegt - ich dachte, ich könnte das OS einfach so installieren, dass ich es zuerst über VNC aufsetzen soll und danach erst "gfx_passthru" aktivieren muss, habe ich nicht gewusst.
Ich hatte die Patches von Tobias schon gefunden gehabt [Xen-devel] GFX Passthrough - Xen Source, bin aber davon ausgegangen, dass die in current unstable schon eingepflegt wurden (war zu faul um nachzuprüfen), deshalb vielen Dank für die beiden Tipps!
Werde gleich patchen und neu bauen.
Bei mir läuft Xen 4.1 unstable ohne Probleme, nur stubdom musste ich mit einem Job kompilieren, bei -j5 geht es schief.
Viele Grüße,
-NM-
das geht ja richtig schnell, mit den Antworten - vielen Dank.
Ok, dann denke ich, weiss ich, wo mein Problem liegt - ich dachte, ich könnte das OS einfach so installieren, dass ich es zuerst über VNC aufsetzen soll und danach erst "gfx_passthru" aktivieren muss, habe ich nicht gewusst.
Ich hatte die Patches von Tobias schon gefunden gehabt [Xen-devel] GFX Passthrough - Xen Source, bin aber davon ausgegangen, dass die in current unstable schon eingepflegt wurden (war zu faul um nachzuprüfen), deshalb vielen Dank für die beiden Tipps!
Werde gleich patchen und neu bauen.Bei mir läuft Xen 4.1 unstable ohne Probleme, nur stubdom musste ich mit einem Job kompilieren, bei -j5 geht es schief.
Viele Grüße,
-NM-
B
Bunkasan
Guest
Immer gern. Viel erfolg, auch wenn ich an deiner stelle das ganze ohne Patches und Passtrough machen würde. 
@Dragontec: Ich muss zu meiner Schande gestehen, das ich aus Zeitmangel das ganze bei einem Xenbridge-internen NFS-Workaround belassen habe. Das Laufwerk wird zwar durchgereicht und erkannt, aber der Datenträger nicht.
@Dragontec: Ich muss zu meiner Schande gestehen, das ich aus Zeitmangel das ganze bei einem Xenbridge-internen NFS-Workaround belassen habe. Das Laufwerk wird zwar durchgereicht und erkannt, aber der Datenträger nicht.
okay, dann bastel ich an meinem bluray laufwerk noch n bissel.. is aber nicht so schlimm, linux hat ja eh schwierigkeiten mit blurays ^^
Sagt mal, habt ihr auch manchmal probleme mit dem bridging? rechnerintern geht das bei mir super, aber mein ssh steigt manchmal aus und der rechner ist nicht so richtig von außen erreichbar.. nach n paar minuten geht das aber wieder und die domUs haben derweil durchgängig zugriff aufs netz.. sprich domU nach draußen geht, shh auf domU / dom0 geht manchmal nicht..
Sagt mal, gibts eigentlich vorteile von:
- gfx_passthrough
- stubdoms
die es lohnend machen das ich an meinem laufenden System noch mal rumbastel, oder meint ihr, bringt nich wirklich viel?
Ach ja, und dann noch n announcement: ich schreib grad verstärkt an nem tutorial für den ganzen mist, also alle Schritte von nem blanken rechner bis hin zu 2 laufenden (Win7, linux) domUs.. Daher fragen an dich Bunkasan: Magst du den ersten Post in dem Threat haben da dein script pflegen, oder meinst du, aus unlust pflegst du das eh nicht und willst deshalb nicht?
Sagt mal, habt ihr auch manchmal probleme mit dem bridging? rechnerintern geht das bei mir super, aber mein ssh steigt manchmal aus und der rechner ist nicht so richtig von außen erreichbar.. nach n paar minuten geht das aber wieder und die domUs haben derweil durchgängig zugriff aufs netz.. sprich domU nach draußen geht, shh auf domU / dom0 geht manchmal nicht..
Sagt mal, gibts eigentlich vorteile von:
- gfx_passthrough
- stubdoms
die es lohnend machen das ich an meinem laufenden System noch mal rumbastel, oder meint ihr, bringt nich wirklich viel?
Ach ja, und dann noch n announcement: ich schreib grad verstärkt an nem tutorial für den ganzen mist, also alle Schritte von nem blanken rechner bis hin zu 2 laufenden (Win7, linux) domUs.. Daher fragen an dich Bunkasan: Magst du den ersten Post in dem Threat haben da dein script pflegen, oder meinst du, aus unlust pflegst du das eh nicht und willst deshalb nicht?
B
Bunkasan
Guest
Also ich konnte bisher noch keine Probleme bei der Bridge feststellen. Weder zuhause noch auf Arbeit, wo es tödlich wäre wenn eine von den Dom0's im RZ nicht von aussen erreichbar wäre.
Einen echten Vorteil hat man vom gfx_passtrough eigentlich nicht, da die karte inzwischen ja eh brauchbar samt bios gemappt wird. Nu gut, Bios und Bootscreen ist das einzige was mir da auf anhieb einfällt.
Stubdoms kann ich nicht viel zu sagen, sollten ein wenig performanter sein, aber ob das wirklich merkbar ist, kA, ich habs nie vernünftig zum laufen bekommen.
Zum Script, das müsste mal aktualisiert und auch noch überarbeitet werden, da fehlts nicht an der Lust, sondern an der Zeit, bei 60-80 Std Arbeit die Woche. Du kannst mir ja mal den zweiten Post als Platzhalter lassen, damit ichs hübsch aufbereitet mit einpflegen kann.
Einen echten Vorteil hat man vom gfx_passtrough eigentlich nicht, da die karte inzwischen ja eh brauchbar samt bios gemappt wird. Nu gut, Bios und Bootscreen ist das einzige was mir da auf anhieb einfällt.
Stubdoms kann ich nicht viel zu sagen, sollten ein wenig performanter sein, aber ob das wirklich merkbar ist, kA, ich habs nie vernünftig zum laufen bekommen.
Zum Script, das müsste mal aktualisiert und auch noch überarbeitet werden, da fehlts nicht an der Lust, sondern an der Zeit, bei 60-80 Std Arbeit die Woche. Du kannst mir ja mal den zweiten Post als Platzhalter lassen, damit ichs hübsch aufbereitet mit einpflegen kann.
nitromaroder
Schraubenverwechsler(in)
Immer gern. Viel erfolg, auch wenn ich an deiner stelle das ganze ohne Patches und Passtrough machen würde.
Jetzt bin ich ein wenig verwirrt - wie soll ich es ohne Patches machen können? Meinst Du, wie DragonTEC vorgeschlagen hat - also ganz normal mit VNC domU aufsetzen, Treiber installieren und die GraKa durchreichen?
Btw., beim current unstable gehen nicht alle Patches durch, "05_sound-makefile" und das "make tool" geht nicht durch:
@DragonTEC: Hm, habe bis jetzt keine Probleme mit dem Bridging gehabt, welche Karte bzw. Modul verwendest Du - hört sich für mich ein wenig nach IRQ-Problemen? Wie sieht denn Dein bridge-setup aus?
MfG,
-NM-
B
Bunkasan
Guest
Punkt 1: Ja, ganz ohne Patches, einfach die Grafikkarte wie jedes andere Gerät durchreichen ohne weitere konfiguration. Installation des Gastsystems über VNC/SDL der emulierten Grafikkarte, nach der Installation konfiguration der "Zweitkarte" als primäres Anzeigegerät. Sowohl unter Windows wie auch Linux möglich.
Zu den Patchen: Bin mir der aktuellen lage nicht absolut bewusst, allerdings wurde das PCI-Passtroughsystem in der 4.1 inzwischen derart verändert das keiner der "alten" Patches noch greift. Sollten die Patches als nicht in der geschwindikeit angepasst worden sein, wie die unstable weiterentwickelt wurde, keine Chance. Hab die auch nur, wie in einem der letzten posts erwähnt, in der 4.0 stable/testing zum laufen bekommen, und das auch nicht wirklich zufriedenstellend.
Zu den Patchen: Bin mir der aktuellen lage nicht absolut bewusst, allerdings wurde das PCI-Passtroughsystem in der 4.1 inzwischen derart verändert das keiner der "alten" Patches noch greift. Sollten die Patches als nicht in der geschwindikeit angepasst worden sein, wie die unstable weiterentwickelt wurde, keine Chance. Hab die auch nur, wie in einem der letzten posts erwähnt, in der 4.0 stable/testing zum laufen bekommen, und das auch nicht wirklich zufriedenstellend.
ohne patches und passthrough geht ganz einfach:
1. installier einfach ein vanilla xen-testing
2. fertig
dann einfach ne neue domU config, bei pci deine graka durchreichen, über vnc installieren und treiber installieren und schon sollte es laufen
fürs unstable sollte das sicher auch so funktionieren, nur leider krieg ich das halt nicht gestartet..
---
mein bridge setup is recht simpel:
ich hab eine bridge von der eth0 zu ner Firewall-DomU (wo auch die dom0) drin hängt) und von der FW aus jeweils eine bridge zu ner anderen domU..
(natürlich ist das nicht final, ich wollt das nur mal testen.. dmz und vpn kommen später)
intern funktioniert das wie gesagt problemlos, nur manchmal zickt das ssh und dann gehen sowohl ssh, als auch ping auf die dom0 mal kurzzeitig nicht.. die eigentlich verbindung funktioniert aber, da die domUs internet haben.. Sobald ich die ersten richtigen Server in den domUs aufgesetzt hab guck ich aber noch mal, ob das vllt nur das ssh is.. aber vorallem beim hoch oder runterfahren von domUs gibts irgendwie kurz probleme..
@ Bunkasan:
ja, kenn ich.. ich hab nur grad projektbedingt n bissel mehr freizeit und will die nutzen, bevor die langen nächte wieder anfangen ich schreib dir dann ne PM wenn ich fertig bin zur abstimmung, dann kriegst du den ersten post und kannst damit machen, was du willst
1. installier einfach ein vanilla xen-testing
2. fertig
dann einfach ne neue domU config, bei pci deine graka durchreichen, über vnc installieren und treiber installieren und schon sollte es laufen
fürs unstable sollte das sicher auch so funktionieren, nur leider krieg ich das halt nicht gestartet..
---
mein bridge setup is recht simpel:
ich hab eine bridge von der eth0 zu ner Firewall-DomU (wo auch die dom0) drin hängt) und von der FW aus jeweils eine bridge zu ner anderen domU..
(natürlich ist das nicht final, ich wollt das nur mal testen.. dmz und vpn kommen später)
intern funktioniert das wie gesagt problemlos, nur manchmal zickt das ssh und dann gehen sowohl ssh, als auch ping auf die dom0 mal kurzzeitig nicht.. die eigentlich verbindung funktioniert aber, da die domUs internet haben.. Sobald ich die ersten richtigen Server in den domUs aufgesetzt hab guck ich aber noch mal, ob das vllt nur das ssh is.. aber vorallem beim hoch oder runterfahren von domUs gibts irgendwie kurz probleme..
@ Bunkasan:
ja, kenn ich.. ich hab nur grad projektbedingt n bissel mehr freizeit und will die nutzen, bevor die langen nächte wieder anfangen
ich schreib dir dann ne PM wenn ich fertig bin zur abstimmung, dann kriegst du den ersten post und kannst damit machen, was du willst nitromaroder
Schraubenverwechsler(in)
Der Murphy ist heute mein Freund... Habe ahnscheinend Mist gebaut, bei meiner Aufräumaktion und kann jetzt keine einzige domU starten:
Viele Grüße,
NM
Hat schon jemand so was in der Art gesehen?
Viele Grüße,
NM
B
Bunkasan
Guest
Jo, check ma deine Bridge.
nitromaroder
Schraubenverwechsler(in)
Habe schon alles überprüft, bin kurz vorm ausrasten!
Und "xm log" spuckt folgendes aus:
Also irgendwie hängt das Ding beim Start und ich raffs nicht wieso:
Im "xend-config.sxp" habe ich "(network-script network-bridge)" auskommentiert und nur der "(vif-script vif-bridge)" ist aktiv - hat auch bis zur xen-unstable alles funktioniert... Jetzt habe ich unstable runter geschmissen, xen-testing drauf, make clean - alles von Anfang an, leider erfolglos...
-NM
Code:
[root@yggdrasil ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:9F:B2:02
inet6 addr: fe80::230:48ff:fe9f:b202/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:917 errors:0 dropped:0 overruns:0 frame:0
TX packets:557 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:194097 (189.5 KiB) TX bytes:216671 (211.5 KiB)
Interrupt:16 Memory:d3400000-d3420000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:70 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7220 (7.0 KiB) TX bytes:7220 (7.0 KiB)
tap2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:22356 (21.8 KiB)
xenbr0 Link encap:Ethernet HWaddr 00:30:48:9F:B2:02
inet addr:192.168.154.1 Bcast:192.168.154.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe9f:b202/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:866 errors:0 dropped:35 overruns:0 frame:0
TX packets:528 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:170530 (166.5 KiB) TX bytes:214333 (209.3 KiB)
[root@yggdrasil ~]# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.0030489fb202 no eth0
tap2.0
Code:
[2011-01-30 20:32:49 1472] DEBUG (XendDomainInfo:1891) XendDomainInfo.handleShutdownWatch
[2011-01-30 20:32:50 1472] DEBUG (DevController:139) Waiting for devices tap2.
[2011-01-30 20:32:50 1472] DEBUG (DevController:139) Waiting for devices vif.
[2011-01-30 20:32:50 1472] DEBUG (DevController:144) Waiting for 0.
[2011-01-30 20:32:50 1472] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/2/0/hotplug-status.
[2011-01-30 20:34:30 1472] DEBUG (XendDomainInfo:3053) XendDomainInfo.destroy: domid=2
[2011-01-30 20:34:30 1472] DEBUG (XendDomainInfo:2411) Destroying device model
[2011-01-30 20:34:30 1472] INFO (image:615) win7-1 device model terminated
[2011-01-30 20:34:30 1472] DEBUG (XendDomainInfo:2418) Releasing devices
[2011-01-30 20:34:30 1472] DEBUG (XendDomainInfo:2424) Removing vif/0
[2011-01-30 20:34:30 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2011-01-30 20:34:30 1472] DEBUG (XendDomainInfo:2424) Removing console/0
[2011-01-30 20:34:30 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = console, device = console/0
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2424) Removing vbd/768
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2424) Removing vbd/5632
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2424) Removing vfb/0
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2416) No device model
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2418) Releasing devices
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2424) Removing vif/0
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2424) Removing vbd/768
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/768
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:2424) Removing vbd/5632
[2011-01-30 20:34:31 1472] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5632
Code:
[root@yggdrasil ~]# xm cre vm00.hvm
Using config file "./vm00.hvm".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.-NM
nitromaroder
Schraubenverwechsler(in)
Hallo nochmal,
sorry für die lange Pause - habe gestern Abend noch ein bisschen gebastelt, das Problem mit vif-error ist weg, kann jedoch immer noch VGA-Passthrough zum laufen bringen:
- Versuch #1 (GT220, Xen 4.1-unstable, ungepatched, 2.6.38-dom0, gfx_passthru=1):
Beim starten von yavdr-0.3a.0 sehe ich VGA-Ausgabe (juhuu, dachte ich mir, leider zu früh) - leider kann X nicht gestartet werden (obwohl die nvidia-module installiert sind).
- Versuch #2 (gleicher setup, nur ohne gfx_passthru):
Ein "startx -- :1" leider auch erfolglos;
- Versuch #3 (ati_patch, HD4350, Xen 4.1-unstable, 2.6.38-dom0):
ATI ist wohl sehr anders als NVidia - hier kommt die Machine nicht über BIOS hinweg, vermutlich weil es nicht auf VGA BIOS zugreiffen kann.
Deshalb habe ich folgende die Fragen an Euch:
- welche Distribution für dom0?
- welche Version des Kernels / Xen-Hypervervisors?
- welche Distri für domU?
- welche Grafikkarte verwendet ihr?
Vielen Dank im Voraus für eure Hilfe!
-NM-
sorry für die lange Pause - habe gestern Abend noch ein bisschen gebastelt, das Problem mit vif-error ist weg, kann jedoch immer noch VGA-Passthrough zum laufen bringen:
- Versuch #1 (GT220, Xen 4.1-unstable, ungepatched, 2.6.38-dom0, gfx_passthru=1):
Beim starten von yavdr-0.3a.0 sehe ich VGA-Ausgabe (juhuu, dachte ich mir, leider zu früh) - leider kann X nicht gestartet werden (obwohl die nvidia-module installiert sind).
- Versuch #2 (gleicher setup, nur ohne gfx_passthru):
Ein "startx -- :1" leider auch erfolglos;
- Versuch #3 (ati_patch, HD4350, Xen 4.1-unstable, 2.6.38-dom0):
ATI ist wohl sehr anders als NVidia - hier kommt die Machine nicht über BIOS hinweg, vermutlich weil es nicht auf VGA BIOS zugreiffen kann.
Deshalb habe ich folgende die Fragen an Euch:
- welche Distribution für dom0?
- welche Version des Kernels / Xen-Hypervervisors?
- welche Distri für domU?
- welche Grafikkarte verwendet ihr?
Vielen Dank im Voraus für eure Hilfe!
-NM-
- dom0: Debian squeeze
- Kernel: suse 2.6.37 mit den suse patches
- domU: Debian squeeze (mit .26er oder 35er ubuntu kernel, der .32 debian will nich bei mir) und Win7
- graka: ati HD5450 und HD5750
vllt noch interessant:
xen-testing, keine patches, kein gfx_passthrough, kein stubdom
Vielleicht solltest du als DomU einfach mal mit einem windows 7 testen? das is mit den grakas ja deutlich gnädiger und wenn das geht kannst du dich daran machen und für linux treiber suchen..
- Kernel: suse 2.6.37 mit den suse patches
- domU: Debian squeeze (mit .26er oder 35er ubuntu kernel, der .32 debian will nich bei mir) und Win7
- graka: ati HD5450 und HD5750
vllt noch interessant:
xen-testing, keine patches, kein gfx_passthrough, kein stubdom
Vielleicht solltest du als DomU einfach mal mit einem windows 7 testen? das is mit den grakas ja deutlich gnädiger und wenn das geht kannst du dich daran machen und für linux treiber suchen..
nitromaroder
Schraubenverwechsler(in)
Vielen Dank für die Antwort! Btw., die 4.0.2-testing mag mich nicht - habe 4.1.0 runtergeschmissen, 4.0.2-testing genommen, gepatched (mit den passthrough patches: 01-05, giingen auch alle durch) und was kommt jetzt wieder - "Error: Device 0 (vif) could not be connected. Hotplug scripts not working."
Mit Xen 4.1 läuft alles rund, nur 4.0.2-testing macht probleme - habe sogar die scripte komplett ausgetauscht (4.0.2 durch 4.1.0) - bleibt immer noch hängen und ich komme nicht drauf, wieso...
Ich berichte, sobald ich was neues habe von der VGA-Passthrough-Front!
Danke nochmals!
-NM-
EDIT: bin wohl nicht der einzige mit Fedora / CentOS und 4.0.2:
http://www.google.de/search?hl=en&client=firefox-a&hs=dzN&rls=org.mozilla%3Ade%3Aofficial&q=4.0.2+Device+%28vif%29+could+not+be+connected.+Hotplug+scripts+not+working+xen&aq=f&aqi=&aql=&oq=
Mit Xen 4.1 läuft alles rund, nur 4.0.2-testing macht probleme - habe sogar die scripte komplett ausgetauscht (4.0.2 durch 4.1.0) - bleibt immer noch hängen und ich komme nicht drauf, wieso...
Ich berichte, sobald ich was neues habe von der VGA-Passthrough-Front!
Danke nochmals!
-NM-
EDIT: bin wohl nicht der einzige mit Fedora / CentOS und 4.0.2:
http://www.google.de/search?hl=en&client=firefox-a&hs=dzN&rls=org.mozilla%3Ade%3Aofficial&q=4.0.2+Device+%28vif%29+could+not+be+connected.+Hotplug+scripts+not+working+xen&aq=f&aqi=&aql=&oq=
Ähnliche Themen
