libvirt, virt-manager und von draussen nach drinnen

[ralfi]

Hallo allesamt,

ich benutze schon einige Zeit libvirt-bin, virt-manager mit qemu / kvm um verschiedene Testumgebungen einzurichten. Dabei verwende ich die per Standard eingerichtete NAT-Funktionalität um von den Testmaschinen nach "draussen" -also in mein normales Netzwerk und weiter- zu kommen. Funktioniert alles wie es soll.

Jetzt brauche ich aber die umgedrehte Funktion, d.h. meine virtuelle Bridge soll als Router für eingehende Verbindungen funktionieren. Das gibt es natürlich auch in den Konfigurationsoptionen für die virtuellen Netzwerke als "Geroutetes Netzwerk". Was ist dann aber noch weiter notwendig, damit eine eingehende Datenverbindung zu den virtuellen Maschinen möglich ist? Das geht bis jetzt nicht.

Danke für jeden Tipp.

[Cae]

Beim "gerouteten Netzwerk" hast du ein eigenes Netz, wo die VM drin haengt. Sobald eine Anfrage ueber das physikalische Interface auf diese IP kommt, wird sie an die VM weiter geroutet. Bei dir passiert vermutlich folgendes: Netz A (VM) und Netz B (physikalische NIC, weitere Rechner) unterscheiden sich, also muss ein System aus Netz B die Anfrage irgendwo hin routen. Weil es Netz A aber nicht kennt, nimmt es den Standardgateway, welcher Netz A aber ebenfalls nicht kennt.

Du musst also eine statische Route (ggf. auch die Rueck-Route dazu) eintragen, das kann global auf dem Standardgateway sein oder nur auf dem Client, der mit der VM sprechen will. Beispiel: Netz A sei 192.0.2.0/24, Netz B sei 10.0.42.0/24, Hypervisor habe 192.0.2.15 an der NIC, dann waere die Route auf dem Standardgateway mit # ip route add 10.0.42.0/24 via 192.0.2.15 die entsprechende Route eingestellt. Anschliessend wird jedes Paket, das an eine VM im 192.0.2.0/24er Netz gerichtet ist, vom Gateway wieder zuerueck in's selbe Netz an den Hypervisor geschickt, welcher intern auf das "geroutete Netzwerk" umroutet und schliesslich die Verbindung an der VM enden laesst.

Gruss Cae

[ralfi]

Hi Cae,
so hatte ich mir das eigentlich auch gedacht.

Ich dachte halt weiter, es gibt so was wie den Router-Ankündigungs-Daemon davd (habsch noch nicht so ganz verstanden...) als Funktionalität in libvirt, wo man einfach ein bisschen in den XML-Files rumfummelt und dann funktioniert eine eingehende Datenverbindung zum libvirt-Netzwerk.

Konkret: Ich habe eine WinXP-VM, mit der ich einige Sache erledigen (muss), die halt nicht mit Linux gehen. Eine von dieser VM ausgehende Datenverbindung (Windows Update Service bspw.) funktioniert natürlich problemlos, aber einen Push-Service von einer Win-Büchse ausserhalb der VM (Virenschutzsoftware verteilen bspw.) geht nicht, da diese Kiste von aussen zwangsläufig keine Verbindung zum VM-Netz aufbauen kann wenn sie die Route nicht kennt. Weiterhin muss ich wohl noch irgendwas mit der NetBIOS over TCP Verbindung falsch konfiguriert haben denn die WinXP-VM will ums Verrecken die Netzwerkumgebung nicht sehen.

Vielen Dank für Deine Hilfe.

[ralfi]

Status-Update (falls es Cae sieht ...) Ich habe jetzt auf Bridge Modus umgestellt und es so konfiguriert, dass sowohl meine in libvirt konfigurierten wie auch mit Qemu gestarteten virtuellen Kisten vollständig im vorhandenen Netzwerk integriert sind inkl. Namensauflösung und allem pie-pa-po.

Nur eines funktioniert nicht und ich bin ziemlich verzweifelt am Suchen:

Ich komme von einer beliebigen virtuellen Maschine nicht über einen Squid Proxy ins Internet. Dieser ignoriert schlicht und ergreifend die Proxy-Variablen der virtuellen Büchse. Und das sowohl über die Konsole mit curl -x, als Konfigurationsvariable in der apt.conf oder auch als KDE Proxy Variable. Die Anfrage an der Firewall stellt sich also so dar als gäbe es die Proxy Konfiguration nicht. Höchst merkwürdig. Vielleicht hat ein Experte das Problem schon einmal gelöst. Und IMHO kann es sich nur um eine Einstellung oder Bug handeln, denn mit VMWare VMs geht es.

[Cae]

Und das sowohl über die Konsole mit curl -x, als Konfigurationsvariable in der apt.conf oder auch als KDE Proxy Variable. Die Anfrage an der Firewall stellt sich also so dar als gäbe es die Proxy Konfiguration nicht. Höchst merkwürdig.

Sehen die Pakete auf der VM auch schon so aus? Kann ich mir zwar schlecht vorstellen, aber vielleicht gibt's eine globale Proxy-Lib, die in der VM kaputt ist. Was natuerlich noch 'ne lustige Variante waere, dass du zwischendrin einen vergessenen Proxy hast, der die Proxy-Header rausfiltert.

Besteht das Problem bei einer VM oder gleich bei allen, die unter qemu laufen?

Gruss Cae

[ralfi]

Hi Cae,

ich habe vergessen Dich zu informieren. Das Problem ist gelöst. Es lag daran, dass TCP Window Scaling nicht deaktiviert war. So kam das Teil nicht über den Proxy.

[Cae]

Interessanter Fehler, interessanter Grund... sollte man sich merken.

Gruss Cae

[ralfi]

Hi Cae,

ja, und auch nur bei Win7 und den von mir eingesetzten Debians. Bei XP geht es ohne diese Modifikation, kann aber sein dass es dort standardmäßig deaktiviert ist.

[ralfi]

Ich habe mich eine ganze Weile mit dem Zeuchs beschäftigt und nun eine ziemlich elegante Lösung mit Hilfe des macvtap Interfaces konfiguriert. Das benötigt keine Modifikationen in der Netzwerkkonfiguration und ist einfach zu konfigurieren. Eigentlich ist es nur die Modifikation der /etc/rc.local (oder eben halt anderer verwendeter Skripts) und die Interface-Einstellung der Qemu-Maschine.

Meine Extrem-Quick-and-Dirty Lösung modfiziert die /etc/rc.local wie folgt

Code: Alles auswählen

sleep 2

# MACVTAP CONFIGURATION FOR USE ETH0 AS BRIDGE WITH LIBVIRTD
ip link add link eth0 name macvtap1 type macvtap mode bridge
ip link set macvtap1 up
ip link add link eth0 name macvtap2 type macvtap mode bridge
ip link set macvtap2 up
ip link add link eth0 name macvtap3 type macvtap mode bridge
ip link set macvtap3 up
ip link add link eth0 name macvtap4 type macvtap mode bridge
ip link set macvtap4 up
ip link add link eth0 name macvtap5 type macvtap mode bridge
ip link set macvtap5 up
ip link add link eth0 name macvtap6 type macvtap mode bridge
ip link set macvtap6 up


sleep 2

# DISABLE ALL IPTABLES
# (automatically created by libvirtd)

/sbin/iptables --flush
/sbin/iptables -X

/sbin/iptables -t filter -P INPUT ACCEPT
/sbin/iptables -t filter -P OUTPUT ACCEPT
/sbin/iptables -t filter -P FORWARD ACCEPT

/sbin/ip6tables -t filter -P INPUT ACCEPT
/sbin/ip6tables -t filter -P OUTPUT ACCEPT
/sbin/ip6tables -t filter -P FORWARD ACCEPT

exit 0

Die Netzwerk-Konfiguration sieht dann wie folgt aus (Ausschnitt):

Code: Alles auswählen

macvtap6  Link encap:Ethernet  Hardware Adresse 2a:b4:26:b4:db:5e  
          inet6-Adresse: fe80::28b4:26ff:feb4:db5e/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:1618669 dropped:1618669 overruns:0 frame:0
          TX packets:79 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX bytes:0 (0.0 B)  TX bytes:9838 (9.6 KiB)

macvtap7  Link encap:Ethernet  Hardware Adresse 52:54:00:b1:db:0b  
          inet6-Adresse: fe80::5054:ff:feb1:db0b/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:3063419 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73382 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX bytes:365759584 (348.8 MiB)  TX bytes:16871692 (16.0 MiB)

virbr0    Link encap:Ethernet  Hardware Adresse 02:1e:d3:ec:23:9f  
          inet Adresse:192.168.122.1  Bcast:192.168.122.255  Maske:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Die zugehörige Netzwerk-Sektion der libvirt Maschine:

Code: Alles auswählen

 <interface type='direct'>
      <mac address='52:54:00:b4:10:71'/>
      <source dev='macvtap1' mode='bridge'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Die macvtap Devices der virtuellen Maschinen sind völlig transparent und bekommen auch o.a. problemlos eine DHCP-Adresse des Netzwerkes. Die virbr0 Schnittstelle der libvirt-Konfiguration kann parallel für Tests etc. weiterbetrieben werden. Zu Testzwecken habe ich die von libvirt automatisch gestartete Firewallkonfiguration deaktiviert, somit "sehen" sich auch alle mit macvtap konfigurierten Maschinen untereinander. Das funktioniert so bei mir nun schon seit einigen Wochen sehr gut.

[tekknokrat]

Hi ralfi,

funktioniert dein macvtap setup noch? Bei Verwendung von macvtap und dem virtio Treiber schläft bei meinem Setup die virtuelle NW Karte nach einiger Zeit ein. Ich kann dann bspw. von meinem Laptop keinen SSH Connect zum Gast machen. Dirty Workaround ist, dann aus dem Gast einen ping oder ähnliches nach draussen abzusetzen. Dann funktioniert die SSH Verbindung wieder

Mein Host/Gast steht im Rechenzentrum. Beides ein aktuelles wheezy (libvirt-bin: 0.9.12.3-1).

[ralfi]

Hi tec..., ich hatte / habe das Glück, noch bis Dienstag im Urlaub verweilen zu dürfen und mich nicht mit blöden Computern rumärgern zu müssen. Dann schaue ich mal nach, selbstredend ist letzte DU schon etwas her.

Allerdings scheint mir Dein Problem mehr nach Power-Management in der virtuellen Kiste zu klingen, was mich auch bei Win7-VMs mal fast zum Wahnsinn trieb. Würde also zunächst testweise alles was nur ansatzweise danach riecht in der VM deaktivieren.

[ralfi]

Kann Symptom nicht nachvollziehen, allerdings allerneuestes libvirt aus exp und qemu 2 aus sid.

[tekknokrat]

Hi Ralfl, kannst Du mal einen xml Abschnitt deiner aktuell laufenden VM Netzwerkconfig posten?

Bei mir sieht der Netzabschnitt folgendermaßen aus:

Code: Alles auswählen

    <interface type='direct'>
      <mac address='52:54:00:aa:8f:5f'/>
      <source dev='eth0' mode='bridge'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Ist das Ganze noch so jung, daß ich mich im aktuellen Wheezy nicht auf den "direct" Typ verlassen kann? Keinerlei Bugreports... Tante google spuckt auch sehr wenig Infos über macvtap aus. Wie setzen denn andere ihr VM Netzwerksetup um? So wie ich gesehen habe setzen jetzt teilweise schon Hoster auf KVM als Hypervisor...

[tekknokrat]

Achso, Power Management Funktionen auf dem KVM Host waren enabled und sind jetzt auf disabled:

Enhanced Intel Speedstep Technology ==> disabled!
Processor C-States ==> disabled!

[ralfi]

Hi,
sorry dass ich so spät antworte, hier habe ich das gestern auch nochmal beschrieben ...

http://debianforum.de/forum/viewtopic.p ... 0&start=15

IMHO schlafen die Büchsen nicht von allein ein. Du könntest nochmal den Loglevel hochsetzen und schauen ob da Fehler auftreten.