ubuntuusers.de

via DuckDuckGo

QEMU-Netzwerkbrücke - Raspberry Pi als QEMU-Guest

Status: Ungelöst | Ubuntu-Version: Lubuntu 13.10 (Saucy Salamander)
Antworten |

herrmeier

Anmeldungsdatum:
5. Oktober 2006

Beiträge: 297
Zitieren
14. März 2014 10:01

Ich habe es geschafft einen raspberry pi mit einem virtualisierten Ubuntu mit QEMU zu emulieren.

Die Anleitung habe ich hier beschrieben

http://forum.ubuntuusers.de/topic/baustelle-raspberry-pi-mit-qemu-emulieren/

, leider konnte ich sie nicht ins WIKI aufnehmen, weil bei "Absenden" unten rechts ein rotes Ausrufezeichen kam - begleitet von "dieses Feld ist zwingend erforderlich." Aber das ist ja Nebensache.

Jetzt würde ich gerne dem emulierten Raspberry Internet aus meinem normalen Adressraum zuweisen. Hierfür ist in der WIKI-Anleitung ein Absatz Netzwerk aufgeführt. Ich traue mich nun aber nicht diesen einfach so zu übernehmen und würde gerne vorher die Vorgang mit Euch abklären. Demnach sollte ich eine bridge im virtualisierten ubuntu 13.10 einrichten. Hier einige infos zum host-system

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
ifconfig
eth0      Link encap:Ethernet  Hardware Adresse 08:00:27:1f:dc:e6  
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:0 (0.0 B)  TX-Bytes:0 (0.0 B)

eth1      Link encap:Ethernet  Hardware Adresse 08:00:00:af:b2:dc  
          inet Adresse:192.168.1.48  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fd00::a00:27ff:feaf:b2dc/64 Gültigkeitsbereich:Global
          inet6-Adresse: fe80::a00:27ff:feaf:b2dc/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:533 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:225 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:54868 (54.8 KB)  TX-Bytes:26957 (26.9 KB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX-Pakete:834 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:834 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX-Bytes:68351 (68.3 KB)  TX-Bytes:68351 (68.3 KB)

virbr0    Link encap:Ethernet  Hardware Adresse 26:dc:d9:71:c8:b1  
          inet Adresse:192.168.122.1  Bcast:192.168.122.255  Maske:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX-Bytes:0 (0.0 B)  TX-Bytes:0 (0.0 B)

1
2
uname -a
Linux ubsrv32bit1310 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:13:28 UTC 2014 i686 i686 i686 GNU/Linux

Hier der betreffende Abschnitt im QEMU-Artikel

Netzwerk Host Der Host ist von einem Gastsystem aus über die IP-Adresse 10.0.2.2 erreichbar. DHCP

Hat man sein Netzwerk per DHCP konfiguriert, sollten Internet und Netzwerk automatisch funktionieren.

QEMU legt allerdings für jede VM ein eigenes Netzwerk an. Es werden IP-Adressen aus dem Bereich 10.0.0.0/8 vergeben. Weiterhin befindet sich jede VM standardmäßig in einem eigenen Netz, sodass Anfragen ins Internet wie gewohnt funktionieren, die VMs sich aber weder untereinander sehen, noch mit physischen Geräten im LAN kommunizieren können. Unter Umständen kann es praktikabel sein, die VMs im gleichen Netz zu betreiben, wie die physischen Geräte. So werden dann beispielsweise die virtuellen Maschinen in die gleiche LAN-Infrastruktur und -Adressraum eingebunden wie die physischen Maschinen. Hierzu ist zunächst die Einrichtung einer Netzwerkbrücke erforderlich. Hierbei ist zu beachten, dass bei der Brücke nicht zwei Netzwerkkarten überbrückt werden (z.B. eth0 und wlan0) sondern nur die Netzwerkkarte, die am LAN angebunden ist. In der /etc/network/interfaces sind also etwa solche Zeilen einzutragen: vergrößern

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
auto br0
iface br0 inet static
address 192.168.1.200
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
bridge_ports eth1
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

eth1 ist in diesem Fall die am LAN angeschlossene Schnittstelle. Die Adressen sind entsprechend den Gegebenheiten anzupassen.

Die Brücke bekommt statisch eine eigene IP-Adresse zugewiesen. Um Konflikte mit der automatischen Adressvergabe des DHCP-Servers zu vermeiden sollte man hier eine wählen, die sich zwar im gleichen Subnetz befindet, aber außerhalb des erlaubten Adressraums des DHCP-Servers liegt (im o.g. Beispiel vergibt der DHCP-Server nur Adressen von 192.168.1.1 bis 192.168.1.100).

Zu beachten ist, dass, wenn man einen Host mit grafischer Oberfläche betreibt, die Verwaltung der Netzwerkkarten u.U. dem Network-Applet der GUI obliegt. Das sollte man für den vorliegenden Fall abschalten, in dem man in der /etc/network/interfaces die für die am LAN angebundene Schnittstelle zuständigen Zeilen wie folgt anpasst:

1
2
3
# The primary network interface
auto eth1
iface eth1 inet dhcp

Im Network-Applet sollte die entsprechende Schnittstelle dann als "wird nicht verwaltet" angezeigt werden.

Beim Starten der VM verwendet man dann das TUN/TAP interface anstelle dem user mode. Das bewerkstelligt man, in dem man das Start-Argument:

-net user (...)

durch ein folgendes ersetzt

-net tap,vlan=1,script="/etc/qemu-ifup"

Das Script sollte bereits an der entsprechenden Stelle vorhanden sein und etwa so aussehen: vergrößern

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
#!/bin/sh

nic=$1

if [ -f /etc/default/qemu-kvm ]; then
    . /etc/default/qemu-kvm
fi

if [ -z "$TAPBR" ]; then
    switch=$(ip route list | awk '/^default / { print $5 }')
    if [ ! -d "/sys/class/net/${switch}/bridge" ]; then
        switch=virbr0
    fi
else
    switch=$TAPBR
fi

1
2
ifconfig $nic 0.0.0.0 up
brctl addif ${switch} $nic

Der Vollständigkeit halber hier noch mal ein komplettes Start-Script für eine Maschine:

1
2
3
#!/bin/sh
# This script created by AQEMU
/usr/bin/qemu-system-x86_64  -smp 2 -cpu phenom -soundhw es1370 -k de -enable-kvm -m 3500 -localtime -hda "/media/raid_a/windows_7_x86.img" -boot once=c,menu=off -net nic,vlan=1,macaddr=00:c9:29:b8:7c:ee -net tap,vlan=1,script="/etc/qemu-ifup" -name "Windows 7 x86" $*

Jetzt sollte die VM beim starten wie eine physische Maschine im LAN eingebunden werden und von überall her erreichbar sein; umgekehrt sollten auch alle Netzwerkressourcen aus dem LAN der VM zur Verfügung stehen.

Meine Frage: Kann ich das copy und paste einfach übernehmen?

herrmeier

(Themenstarter)

Anmeldungsdatum:
5. Oktober 2006

Beiträge: 297
Zitieren
18. März 2014 09:08

weitere Anleitung

Hier habe ich noch etwas gefunden...

KVM Networking 🇬🇧

Assign CAP_NET_ADMIN Capability

Bridged networking does not work by default. Since the release of kernel 2.6.18 in Sep 2006, the CAP_NET_ADMIN capability is required to use TUN/TAP networking (bug #103010).

Install the qemu package (qemu-kvm in lucid or newer):

sudo apt-get install qemu

Install the Linux capabilities tools:

sudo apt-get install libcap2-bin

Ubuntu 10.4 (Lucid) and later - Grant specific users the CAP_NET_ADMIN capability. This capability should be assigned cautiously, as it will allow those users to disrupt all networking on the system.

Give qemu the inheritable CAP_NET_ADMIN capability

for 64-bit: sudo setcap cap_net_admin=ei /usr/bin/qemu-system-x86_64

for 32-bit: sudo setcap cap_net_admin=ei /usr/bin/qemu-system-i386

> Allow specific users to gain the inheritable CAP_NET_ADMIN capability by editing /etc/security/capability.conf:

cap_net_admin USER-NAME-HERE Releases prior to Ubuntu 10.4 (Lucid) - Grant all users the CAP_NET_ADMIN capability. Use with extreme caution as it will give all users the ability to disrupt all networking on the system. Give qemu the forced CAP_NET_ADMIN capability: sudo setcap cap_net_admin=ep /usr/bin/qemu-system-* Note that the filesystem capabilities above will be lost on every qemu upgrade, since setting of the file system capability is not supported by Ubuntu packaging (see FilesystemCapabilities for details on the blockers). For a good overview of Linux capabilities and QEMU see this writeup.

Problem:

https://linux.kernel.org/pub/linux/libs/security/linux-privs/ wird nicht gefunden!

1
cap_net_admin        USER-NAME-HERE

wird in der conf bisher nicht angeboten... Ein "rtfm" hilft mir wegen fehlender Anleitung nicht weiter...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
#
# /etc/security/capability.conf
#
# this is a sample capability file (to be used in conjunction with
# the pam_cap.so module)
#
# In order to use this module, it must have been linked with libcap
# and thus you'll know about Linux's capability support.
# [If you don't know about libcap, the sources for it are here:
#
#   http://linux.kernel.org/pub/linux/libs/security/linux-privs/
#
# .]
#
# Here are some sample lines (remove the preceding '#' if you want to
# use them

## user 'morgan' gets the CAP_SETFCAP inheritable capability (commented out!)
#cap_setfcap            morgan

## user 'luser' inherits the CAP_DAC_OVERRIDE capability (commented out!)
#cap_dac_override       luser

## 'everyone else' gets no inheritable capabilities (restrictive config)
none  *

## if there is no '*' entry, all users not explicitly mentioned will
## get all available capabilities. This is a permissive default, and
## possibly not what you want... On first reading, you might think this
## is a security problem waiting to happen, but it defaults to not being
## so in this sample file! Further, by 'get', we mean 'get in their inheritable
## set'. That is, if you look at a random process, even one run by root,
## you will see it has no inheritable capabilities (by default):
##
##   $ /sbin/capsh --decode=$(grep CapInh /proc/1/status|awk '{print $2}')
##   0000000000000000=
##
## The pam_cap module simply alters the value of this capability
## set. Including the 'none *' forces use of this module with an
## unspecified user to have their inheritable set forced to zero.
##
## Omitting the line will cause the inheritable set to be unmodified
## from what the parent process had (which is generally 0 unless the
## invoking user was bestowed with some inheritable capabilities by a
## previous invocation).
Antworten |