Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

Qemu, NAT Networking und unverständliches Wiki

Alles rund um die Systemverwaltung, die Administration und Konfiguration Eures Linuxsystems

Moderator: Moderatoren

Antworten
Blackscreen
Member
Member
Beiträge: 123
Registriert: 6. Mai 2006, 20:27

Qemu, NAT Networking und unverständliches Wiki

Beitrag von Blackscreen » 19. Aug 2007, 23:40

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.

Werbung:
b3ll3roph0n
Moderator
Moderator
Beiträge: 3669
Registriert: 4. Dez 2005, 13:17
Kontaktdaten:

Beitrag von b3ll3roph0n » 20. Aug 2007, 01:57

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: Alles auswählen

KERNEL=="tun",			NAME="net/%k", MODE="0666"
auf

Code: Alles auswählen

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: Alles auswählen

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: Alles auswählen

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: Alles auswählen

-net nic -net tap,ifname=tap0,script=qemu-ifup
starten.
Das Script qemu-ifup sollte wie folgt aussehen:

Code: Alles auswählen

#!/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: Alles auswählen

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: Alles auswählen

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: Alles auswählen

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: Alles auswählen

#!/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)
Gruß b3ll3roph0n
--
Denken hilft!

Ich beantworte keine Support-Anfragen per PN.
Für alle meine Beiträge gelten, außer bei Zitaten, die Creative Commons.

Benutzeravatar
nbkr
Guru
Guru
Beiträge: 2857
Registriert: 10. Jul 2004, 15:47

Beitrag von nbkr » 20. Aug 2007, 09:21

Kann gar nicht sein, ich bin gefürchtet Wald aus, Wald ein.

Blackscreen
Member
Member
Beiträge: 123
Registriert: 6. Mai 2006, 20:27

Beitrag von Blackscreen » 20. Aug 2007, 23:48

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: Alles auswählen

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: Alles auswählen

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?!

b3ll3roph0n
Moderator
Moderator
Beiträge: 3669
Registriert: 4. Dez 2005, 13:17
Kontaktdaten:

Beitrag von b3ll3roph0n » 21. Aug 2007, 03:56

Blackscreen hat geschrieben: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 hat geschrieben:@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 hat geschrieben:Und warum zum Geier funktionert mein sudoers Eintrag nicht:
Ende von /etc/sudoers:

Code: Alles auswählen

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: Alles auswählen

/usr/bin/tunctl -b -u b3ll3roph0n, \
/usr/bin/tunctl -u b3ll3roph0n -t *, \
/usr/bin/tunctl -d *
Blackscreen hat geschrieben: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:
Gruß b3ll3roph0n
--
Denken hilft!

Ich beantworte keine Support-Anfragen per PN.
Für alle meine Beiträge gelten, außer bei Zitaten, die Creative Commons.

Blackscreen
Member
Member
Beiträge: 123
Registriert: 6. Mai 2006, 20:27

Beitrag von Blackscreen » 21. Aug 2007, 23:47

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: Alles auswählen

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: Alles auswählen

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?

b3ll3roph0n
Moderator
Moderator
Beiträge: 3669
Registriert: 4. Dez 2005, 13:17
Kontaktdaten:

Beitrag von b3ll3roph0n » 22. Aug 2007, 03:58

Blackscreen hat geschrieben:

Code: Alles auswählen

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: Alles auswählen

/sbin/ip link set tap* up, \
Du solltest also auch noch das deakvieren des Devices erlauben:

Code: Alles auswählen

/sbin/ip link set tap* down, \
Evtl. funktioniert auch ein

Code: Alles auswählen

/sbin/ip link set tap* [up|down], \
In jedem Fall sollte es mit der Wildcard funktionieren

Code: Alles auswählen

/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).
Gruß b3ll3roph0n
--
Denken hilft!

Ich beantworte keine Support-Anfragen per PN.
Für alle meine Beiträge gelten, außer bei Zitaten, die Creative Commons.

Blackscreen
Member
Member
Beiträge: 123
Registriert: 6. Mai 2006, 20:27

Beitrag von Blackscreen » 22. Aug 2007, 21:26

lol - Anscheinend ging mir genau während du deinen Post geschrieben hast ein Licht auf woraufhin ich meinen letzten Post editiert habe :lol:
b3ll3roph0n hat geschrieben:...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: Alles auswählen

/sbin/ip link set tap* up, \
Du solltest also auch noch das deakvieren des Devices erlauben:

Code: Alles auswählen

/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 hat geschrieben:...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)?

Antworten