Xen - mehr als 3 NICs in HVM-VM unmöglich?

[Bigfoot29]

Hi!

Ich hab mich heute den ganzen Tag abgequält, in Debian 10 unter Xen (4.11) mehr als 3 Netzwerk-Karten für einen HVM-Gast zum Laufen zu kriegen. Ich kann zwar problemlos via paravirt-DomU - also mit reinen Xen-Boardmitteln - 4 Netzwerkkarten einrichten, aber sobald QEMU ins Spiel kommt und mit Xen zusammenwerkeln soll, ist bei Dreien Schluss. Sowohl direkt via "xl" (Xen Boardmittel) als auch via "virsh" (Abstraktionsebene "libvirt") streikt Xen mit der Fehlermeldung:

libxl: error: libxl_dm.c:2427:device_model_spawn_outcome: Domain XY:domain XY device model: spawn failed (rc=-3)

Kann das von euch ggf. mal jemand testen, ob bei euch in gleicher Config mehr geht?

Alternativ wäre es auch interessant, wenn jemand von euch wüsste, wie man Xen via HVM dazu zwingen kann, ein Q35-Template (anstelle des 440ers) zu verwenden. Die Hardware-Limitierungen könnten zumindest daher stammen, dass der 440er nicht genug virtuelles RAM zugewiesen bekommt, um genügend Hardware in den Registern zu halten. - Hab ich heute zumindest gelesen, dass es dieses Problem bei PCI-Bridges in Verbindung mit dem 440er gibt.
Aber auch dort ist Xen keinerlei Konfigurationsmöglichkeit zu entlocken... :S

So langsam gibt das Internet nicht mehr viele Infos her. Wenn man via LibVirt mit Xen virtualisieren will, kann man (scheinbar, habs zumindest nicht zum Laufen bekommen) im XML keine "model"-Infos mitgeben, Xen selbst weigert sich völlig, abgesehen von hartcodiertem Zeug irgend etwas anzubieten und der Domainbuilder (Teil von Xen) spuckt dazu dann ein

xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 <= matches

aus, anstatt korrekt das erst später zu testende "xc_dom_compat_check: supported guest type: hvm-3.0-x86_64" zu nutzen. Bin ich hier etwa auf einen Bug gestoßen?

Danke euch im Voraus!

Regards, Bigfoot29

PS: Bitte keine Diskussion, dass es mit VMWare,KVM, Insert-Virtualisierungslösung-Here, ... ginge. Das glaube ich sofort. Allerdings würden die laufenden VMs bei Weitem bei Vollvirtualisierung nicht mehr in das nötige RAM passen. Und bei PV ist Xen performancetechnisch unschlagbar.

Nachtrag: Ziel der Aktion ist ein Testlauf einer pfSense-Firewall. Die arbeitet mit BSD. Dafür gibt es zwar ebenfalls Xen-Support, allerdings nicht vom pfSense-Hersteller. Ergo sollen die Tests erstmal mit HVM - also voller Virtualisierung laufen. Nur.. genau da liegt eben der Hase im Pfeffer. -.-'

 

[madmax2010]

Du musst das tun modulo laden - Die Anzahl ist nicht das problem. Dein returncode ist -3

 

[Bigfoot29]

Hi @madmax2010
Vielen Dank für die Antwort!

Das Modul "tun" ist geladen (sagt lsmod). Es hätte mich auch gewundert, wenn dem nicht so wäre. Ich kann 3 Interfaces problemlos einbinden. Erst ab dem Vierten gibt es diese Meldung. Und das auch nur, wenn die VM als "HVM" (voll/teilweise virtualisiert mit QEMU) läuft und nicht im paravirt-Modus (xen direkt). Kann das Zusammenspiel Xen <-> QEMU hier eine Macke haben? Oder übersehe ich einen kapitalen Bock, den ich selber geschossen habe? grübel

Regards, Bigfoot29

 

[Bigfoot29]

So, ich kann es mir selber beantworten, nachdem ich noch ein paar Wochen Debugging drangehangen habe... ;__;

Ursache: Ein Bug, der seit 2014 offen ist. --> https://lists.xenproject.org/archives/html/xen-users/2016-06/msg00086.html

Lösung: Es dürfen in HVM-Umgebungen (vollvirtualisierte Gäste wie Windows) maximal 3 Interfaces den Typ "type=ioemu" (Default-Typ bei HVMs) in der Konfiguration haben. Alle anderen dürfen nur "type=vif" sein. Bei ioemu gibt es parallel zum "vif" noch ein Interface, welches unmodifizierte Betriebssysteme nutzen können. Und davon gehen maximal 3 gemäß Bug.

[...]
vif = [ 'type=vif, mac=xx:xx:xx:xx:xx:xx, bridge=bla01', [...] ]
[...]

Regards, Bigfoot29

 

[madmax2010]

Oh wow
Danke für die Auflösung