• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Qemu, NAT Networking und unverständliches Wiki

Moin,

ich will Qemu (bzw. KVM) dazu bringen das Netzwerk per NAT (also so wie standardmäßig in VMware) einzubinden so daß die realen & virtuellen PCs in einem Netz sind (192.168.1.0/24).

Da ich weder im Internet eine verständliche Erklärung gefunden habe noch mit dem Wiki Eintrag etwas anfangen kann wäre ich extrem dankbar wenn mir das einer verständlich darlegen könnte.

Istzustand ist: Virtuelle Maschinen haben Internetzugang und bekommen IPs wie 10.x.x.x.
Das Problem mit dem Wiki Eintrag ist: /etc/udev/udev.rules und /etc/udev/devfs.rules existieren bei mir nicht und was der folgenden Blöcke in welche Dateien gehört bzw. wann die Skripten ausgeführt werden müßen bzw. wie ich Qemu dann dazu bringe das (wahrscheinlich br0) zu benutzen ist mir schleierhaft.

Besten Dank.

€: Für den Fall dass das nicht ganz klar wurde: Die Intention ist also dass sowohl dem Host als auch den Gästen ganz nach belieben statische oder dynamische IPs zugewiesen werden können die sich im selben Netz (192.168.1.0/24) befinden.
 
Sry, das ist leider nie fertig geworden ...
(was da steht war eher ein Brainstorming)
... ich bin mittlerweile auf vmware umgestiegen. :wink:

Benötigte Pakete: iproute, bridge-utils (, uml-utilities)

UDEV:
Die Änderungen sind eigentlich nicht unbedingt notwendig, da /dev/tun mittlerweile mit den Rechten 666 angelegt wird.
Wenn du aber trotzdem eine qemu-Gruppe anlegen verwenden willst:
In der Datei /etc/udev/rules.d/50-udev-default.rules den Eintag
Code:
KERNEL=="tun",			NAME="net/%k", MODE="0666"
auf
Code:
KERNEL=="tun",			NAME="net/%k", MODE="0660", GROUP="qemu"
ändern.

Bridge:
Eine Bridge br0 mit einem Interface (deinem normalen IFace) anlegen.
Das von Qemu angelegte tap-Device wird dann zu dieser Bridge hinzugefügt.
Die Bridge kannst du über die ifcfg-Dateien in /etc/sysconfig/network einrichten ober über ein entsprechendes Script.

Bsp:
/etc/sysconfig/network/ifcfg-eth-id-0a:0b:0c:0d:0e:0f
Code:
BOOTPROTO='static'
IPADDR='10.0.1.1'
NAME='Ethernet'
NETMASK='255.255.255.0'
STARTMODE='auto'
USERCONTROL='no'
PREFIXLEN=''
/etc/sysconfig/network/ifcfg-br0
Code:
BOOTPROTO='dhcp'
STARTMODE='auto'
USERCONTROL='no'
NAME='Bridge'
NETMASK='255.255.255.0'
Bitte beachten (für Firewalls, etc.): Der Netzverkehr läuft jetzt über br0.

Alternative:
Die Bridge bei Bedarf über ein Script setzen.
Ein entsprechendes Script hatte ich hier mal gepostet: http://phpfi.com/228994

Qemu:
Qemu dann mit den Parametern
Code:
-net nic -net tap,ifname=tap0,script=qemu-ifup
starten.
Das Script qemu-ifup sollte wie folgt aussehen:
Code:
#!/bin/sh
BRIF=br0;
sudo /usr/sbin/ip link set $1 up
sudo /usr/sbin/brctl addif $BRIF $1
Dazu in der /etc/sudoers eintragen:
Code:
User_Alias      QEMU_USER = deinUser

Cmnd_Alias      KQEMU = /usr/sbin/ip link set tap* up, \
                        /usr/sbin/brctl addif br0 *

QEMU_USER    deinHostname = NOPASSWD: KQEMU


Evtl. muss das tap-Device erst noch angelegt werden:
Dazu das Paket uml-utilities installieren.

Vor dem Start von Qemu ausführen:
Code:
sudo /usr/bin/tunctl -u deinUser -t tap0;
(den Aufruf von tunctl kannst du natürlich auch in die /etc/sudoers eintragen)

Wenn du willst, kannst du nach Qemu auch noch aufräumen:
Code:
sudo /usr/sbin/brctl delif br0 tap0;
sudo /usr/sbin/ip link set tap0 down;
sudo /usr/bin/tunctl -d tap0;

Ich hatte mir dazu seinerzeit mal ein kleines Script geschrieben:
Code:
#!/bin/sh
# /usr/local/bin/qemu-start
# startup-script for qemu using tapped networking

PRGNAME=$(basename $0)
readonly HELP="Usage: $PRGNAME -hda /path/to/image.img -m 192 [-cdrom /dev/hdc -boot d]";

function usage { ( echo -e "$HELP" ) >&2; };

if [ $# -eq 0 ]; then
  usage; exit 100;
 else
   
   BRIF=br0;
   QEMU="/usr/bin/qemu";
   OPTS="-kernel-kqemu -k de -localtime";
   IFUP="/usr/local/bin/qemu-ifup";
   USER=`whoami`;
   IFTA=`sudo /usr/bin/tunctl -b -u $USER`;

   sudo /sbin/modprobe kqemu;
   sudo /sbin/modprobe tun;
   sudo /usr/bin/tunctl -u $USER -t $IFTA;

   $QEMU $OPTS $@ -net nic -net tap,ifname=$IFTA,script=$IFUP;

   sudo /usr/sbin/brctl delif $BRIF $IFTA;
   sudo /usr/sbin/ip link set $IFTA down;
   sudo /usr/bin/tunctl -d $IFTA;

fi;

# End of file


PS: Wenn du Lust hast (und das ganze bei dir läuft) kannst du das im WIKI gerne vervollständigen.
(Bei Rückfragen stehe ich in dem Fall auch PN zur Verfügung)
 

nbkr

Guru
Guckst Du auch hier:
http://www.benjaminfleckenstein.de/de/anleitungen/anl_netzwerkbruecke.html
 
OP
B

Blackscreen

Member
Herzlichen Dank für eure Antworten!

Ich habe es mittlerweile laufen aber es gibt dabei noch ein paar Probleme (eth0 is mein Ethernet und br0 die Bridge):

1. Die Firewall blockiert die Gastsysteme wobei eth0 als Externe Zone deklariert ist. Auch wenn ich br0 explizit als Interne Zone deklariere werden die Gäste geblockt.

Wie kann ich die Firewall so einstellen dass einerseits mein PC geschützt ist und andererseits auch die Gäste Zugriff auf das Internet haben (Sie müssen, außer von meinem PC aus (localhost), nicht unbedingt erreichbar sein)?

2. Gibt es für Qemu sowas wie VMware Tools, d.h. dass die Maus automatisch freigegeben bzw. eingefangen wird wenn man sie über das Qemu Fenster bewegt?

3. Normalerweise ging die Auflösung nur bis 800x600. Mit Vesa Treibern und 16-Bit Farbtiefe lässt sie sich auch größer einstellen. Gibt es einen Trick dass das auch mit 24-Bit Farbtiefe funktioniert.

4. @b3ll3rophon: VMware war bis jetzt auch immer meine rundum sorglos Lösung aber mit der aktuellen Version werde ich nicht glücklich! Öfter als nicht bleibt das System hängen oder braucht ewig und reißt mir meistens auch den Host in den virtuellen Abgrund (z.B. In Windows XP SP2 mit IE6 auf die Windows Update Seite). Früher ist sowas eigentlich nie passiert aber jetzt will ichs deswegen in die Tonne kloppen. Hast du keine solchen Abstürze / Probleme? Auch ist der Geschwindigkeitsvorteil im Vergleich zu KVM mittlerweile nicht mehr vorhanden (Windows geht zwar subjektiv gefühlt etwas langsamer aber dafür läuft Linux wesentlich schneller bzw. bleibt nicht so oft & lange hängen)

5. Und warum zum Geier funktionert mein sudoers Eintrag nicht:
Ende von /etc/sudoers:
Code:
User_Alias      QEMU_USER = ich

Cmnd_Alias      KQEMU = /sbin/ip link set tap* up, \
                        /sbin/brctl addif br0 *, \
                        /usr/bin/tunctl -b -u *, \
                        /usr/bin/tunctl -u * -t *, \
                        /usr/bin/tunctl -d *

QEMU_USER    localhost = NOPASSWD: KQEMU
Aufruf (wie in b3ll3rophons Sript):
Code:
IFTA=`sudo /usr/bin/tunctl -b -u $USER`;
Sollte doch theoretisch stimmen? Außerdem sollte doch "/usr/bin/tunctl *" anstatt der 3 Zeilen möglich sein?!
 
Blackscreen schrieb:
Gibt es für Qemu sowas wie VMware Tools, d.h. dass die Maus automatisch freigegeben bzw. eingefangen wird wenn man sie über das Qemu Fenster bewegt?
Hmm, IIRC hat Stefan Becker in seinem HowTo so etwas beschrieben ...
=> http://www.linuxforen.de/forums/showthread.php?t=141201
Stichwort: Übergangslose Maus (Post 6)

Blackscreen schrieb:
@b3ll3rophon: VMware war bis jetzt auch immer meine rundum sorglos Lösung aber mit der aktuellen Version werde ich nicht glücklich!
[...]
Hast du keine solchen Abstürze / Probleme? Auch ist der Geschwindigkeitsvorteil im Vergleich zu KVM mittlerweile nicht mehr vorhanden (Windows geht zwar subjektiv gefühlt etwas langsamer aber dafür läuft Linux wesentlich schneller bzw. bleibt nicht so oft & lange hängen)
Ich nutze sein knapp einem halben Jahr VMWare (VMWare Server) und hatte bis jetzt noch keine (durch VMware verursachte) Abstürze.
Allerdings laufen bei mir auch zum größten Teil Linux-Systeme in der VM - Windows (= WinXP) nutze ich eigentlich zu selten und nicht intensiv genug um große Stabilitätsprobleme ausmachen zu können.

Was die Geschwindigkeit angeht, muss ich gestehen, dass ich die aktuellen Qemu/KVM-Versionen nicht getestet habe ...
... mit dem Umstieg von Qemu auf VMWare (vor, wie gesagt, einem halben Jahr) hatte ich schon einen leichten Geschwindigkeitsvorteil von VMWare gegenüber Qemu feststellen können ...

Das "Killerfeature" von VMWare ist für mich momentan die VMWare-Server-Console.
Der Server läuft bei mir auf einem Rechner ohne graphische Oberfläche und ich verbinde mich eigentlich nur via VMWare-Console oder ssh (Linux) bzw. rdesktop (Windows) mit den VMs.

Blackscreen schrieb:
Und warum zum Geier funktionert mein sudoers Eintrag nicht:
Ende von /etc/sudoers:
Code:
User_Alias      QEMU_USER = ich

Cmnd_Alias      KQEMU = /sbin/ip link set tap* up, \
                        /sbin/brctl addif br0 *, \
                        /usr/bin/tunctl -b -u *, \
                        /usr/bin/tunctl -u * -t *, \
                        /usr/bin/tunctl -d *

QEMU_USER    localhost = NOPASSWD: KQEMU
Benutz mal deinen "richtigen" Hostnamen anstatt localhost.

Außerdem hatte ich IIRC immer den Usernamen mit angegeben, anstatt der Wildcard:
Code:
/usr/bin/tunctl -b -u b3ll3roph0n, \
/usr/bin/tunctl -u b3ll3roph0n -t *, \
/usr/bin/tunctl -d *

Blackscreen schrieb:
Sollte doch theoretisch stimmen? Außerdem sollte doch "/usr/bin/tunctl *" anstatt der 3 Zeilen möglich sein?!
Ja, /usr/bin/tunctl * bzw. /usr/bin/tunctl (ohne Wildcard) sollte auch funktionieren.
Ich habe mir bloß angewöhnt die Rechte in der /etc/sudoers so restriktiv wie möglich zu setzen. :wink:
 
OP
B

Blackscreen

Member
Abermals vielen Dank für deine Antwort!

€: Ich habe das Problem mit dem Host in /etc/sudoers gelöst indem ich ALL statt localhost verwendet habe und nicht mehr die Befehle verwechselt habe :oops:.

Trotzdem stehe ich vollkommen im Wald wie die Firewall korrekterweise konfiguriert werden sollte (mit ausgeschalteter FW funktioniert alles einwandfrei).

Kurz gesagt: Eine Bridge br0 wurde erstellt, eth0 (mit IP 0.0.0.0) daran angebunden und br0 mit statischer IP konfiguriert (für den Host). Das funktioniert einwandfrei.
Per Skript werden immer beim Start von KVM tapx Interfaces erstellt und an br0 angebunden bzw. nach Beendigung wieder von br0 entfernt. Die Gäste beziehen dabei entweder per DHCP IP Adressen oder geben sich statische IPs im lokalen Netz 192.168.1.0/24.

Meinem Verständnis nach müßten also Pakete von eth0 nach tapx und umgekehrt von der Firewall geforwarded werden - d.h. ich habe
Code:
iptables -I FORWARD -i eth0 -o tap0 -j ACCEPT
iptables -I FORWARD -i tap0 -o eth0 -j ACCEPT
ausgeführt und "iptables -L -v -n" zeigt (für die FORWARD Kette) folgendes an:
Code:
Chain FORWARD (policy DROP 2 packets, 656 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  tap0   eth0    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  eth0   tap0    0.0.0.0/0            0.0.0.0/0
    2   656 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWD-ILL-ROUTING '
Was für mich korrekt aussieht aber nicht funktioniert :evil:

Also wo liegt da der Denkfehler bei der Firewallkonfiguration?
 
Blackscreen schrieb:
Code:
sudo /sbin/ip link set tap0 down
--->root's password:<---
--->sudo /usr/bin/tunctl -d tap0<---
Set 'tap0' nonpersistent
Wieso bitte funktioniert die sudoers Konfiguration nicht für den letzten tunctl Aufruf (für die ersten 2 funktioniert es einwandfrei)?
Das müsste dann doch die Passwortabfrage für ip sein, nicht für tunctl.
Du erlaubst in der /etc/sudoers nur das aktivieren des Interfaces:
Code:
/sbin/ip link set tap* up, \
Du solltest also auch noch das deakvieren des Devices erlauben:
Code:
/sbin/ip link set tap* down, \
Evtl. funktioniert auch ein
Code:
/sbin/ip link set tap* [up|down], \
In jedem Fall sollte es mit der Wildcard funktionieren
Code:
/sbin/ip link set tap* *, \

Bezüglich der Firewall ... ich hatte Qemu eigentlich nur auf Rechnern im internen Netz laufen, also entweder ohne Firewall oder nur mit der SuSEfirewall eine interne Schnittstelle zugewiesen.

Die tapX-Devices brauchst du nicht gesondert behandeln, die setzen sich nur auf die Bridge auf.
Die eigentliche Netzwerkkarte (eth0) kannst du auch vernächlässigen, da der Netzverkehr dann offiziell br0 läuft.

IIRC:
br0 => Interne/Externe Zone
eth0 => keine Zone
(mit der SuSEfirewall)

Wenn du eigene Iptables-Regeln verwendest müsste es IMHO reichen, die Firewall ganz normal einzurichten - also mit br0 anstatt des regulären Interfaces und ohne die Tap-Devices gesondert zu behandeln.

Auf jeden Fall brauchst du kein Routing/Forwarding für die Tap-Devices, das erledigt doch die Bridge für dich. :wink:


PS: 0.0.0.0 würde ich nicht unbedingt als statische IP für eth0 benutzen.
Da kannst du einfach eine feste IP aus dem private IP-Adressbereich wählen (natürlich ein anderes Subnetz, als dein eigentliches LAN).
 
OP
B

Blackscreen

Member
lol - Anscheinend ging mir genau während du deinen Post geschrieben hast ein Licht auf woraufhin ich meinen letzten Post editiert habe :lol:
b3ll3roph0n schrieb:
...Das müsste dann doch die Passwortabfrage für ip sein, nicht für tunctl.
Du erlaubst in der /etc/sudoers nur das aktivieren des Interfaces:
Code:
/sbin/ip link set tap* up, \
Du solltest also auch noch das deakvieren des Devices erlauben:
Code:
/sbin/ip link set tap* down, \
...
Genau daran lag es :oops:.

In Sachen Firewall: da geht immer noch nichts :(. br0 ist jetzt als externe Zone konfiguriert und eth0 als Interne (d.h. keinerlei Beschränkungen). Aber es muss an der Firewall liegen da alles einwandfrei funktioniert sobald sie ausgeschaltet ist. "iptables -L -v -n" zeigt FOLGENDES an. Woran könnte es also liegen?

b3ll3roph0n schrieb:
...PS: 0.0.0.0 würde ich nicht unbedingt als statische IP für eth0 benutzen.
Da kannst du einfach eine feste IP aus dem private IP-Adressbereich wählen (natürlich ein anderes Subnetz, als dein eigentliches LAN).
Danke für den Hinweis aber was genau ist daran gefährlich bzw. was genau bedeutet IP 0.0.0.0 (ich dachte einfach keine IP und Daten werden nur durchgeleitet zu br0)?
 
Oben