KVM bridged VM mit zwei eth-Interfaces[solved]

Hallo nochmal,

leider weiß ich jetzt immer noch nicht genau wie ich mein Szenario umsetze. Vielleicht hat jemand eine Idee:

Ich habe im UVMM eine VM erstellt, ein vorhandes qcow2 Image eingebunden, gebootet, funktioniert. Die VM ist Ubuntu 14.04 LTS. Es handelt sich um ein Gateway zum Verschlüsseln von Emails. Dieses lief vorher auf einem Microsoft SBS 2011 unter VMware Workstation als Shared-VM mit einem bridged Netzwerk-Adapter. Innerhalb der VM gibt es jedoch 2 Netzwerkinterfaces: eth0, eth1 welche sich unter ifconfig auflisten lassen. Diesen ist jeweils eine IP-Adresse zugewiesen, auf die ich über HTTP zugreifen kann und auf eine WebGUI des Gateways komme.

Nun zum eigentlichen Problem in UCS: VM läuft, laut Handbuch wird “In der Grundeinstellung wird mit einer Bridge auf dem Virtualisierungsserver direkt auf das Netz zugegriffen.” Heißt ich habe der VM unter Geräte > Netzwerkschnittstellen nichts angelegt. 1. Muss ich hier ein oder sogar mehrere Schnittstellen anlegen, wenn ja, welche? 2. Lege ich hier eine Bridge an, so möchte er eine Quelle br0 haben, die es anscheinend nicht gibt. Muss ich dieses zusätzlich irgendwo erstellen? Wenn ja, wo und wie? Ich habe es getestet indem ich es einfach eingetragen habe, bekomme aber beim Starten der VM folgende Meldung: “Cannot get interface MTU on ‘br0’: No such device”.
Mit NAT hat es funktioniert, löst aber nicht mein Problem, auf die WebGUI zugreifen zu können, etc.

Hier einmal die jetzigen Einstellungen aus UMC:


Vorher war eth0 der eigentliche Port mit der statischen IP-Adresse, keine Ahnung warum das getauscht wurde.
Bin mittlerweile etwas verwirrt, vielleicht habe ich auch nur einen Denkfehler. Danke schon mal und schönes Wochenende!

Moin,

normalerweise wird auf einem UVMM automatisch eine Bridge konfiguriert, die dann auch als primäres Interface benutzt wird; siehe Doku. Wenn bei Ihnen das Interface also nicht da ist, dann ist das schon mal nicht so prall. Bevor wir also die Konfiguration der virtuellen Maschine anpassen können, müssen wir erst einmal dafür sorgen, dass die Bridge doch da ist.

Pasten Sie bitte mal die Ausgabe der folgenden Befehle:

ucr search --brief interfaces/br0
ucr get interfaces/primary
ip address show
brctl show

LG,
mosu

Hallo,

danke für die Unterstützung!
Hier die Ausgabe der Befehle:

root@ucs:~# ucr search --brief interface/br0
root@ucs:~# ucr get interfaces/primary
br0
root@ucs:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 90:1b:0e:ac:3b:c0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.56/24 brd 192.168.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::921b:eff:feac:3bc0/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 90:1b:0e:ac:7d:08 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:32:de:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:32:de:32 brd ff:ff:ff:ff:ff:ff
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:11:fa:66:a0 brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever
root@ucs:~# brctl show
bridge name	bridge id		STP enabled	interfaces
docker0		8000.024211fa66a0	no		
virbr0		8000.52540032de32	yes		virbr0-nic
root@ucs:~# 

OK das ist komisch, es gibt zwar eine Bridge virbr0, aber in der ist nur eine NIC virbr0-nic, die down ist. Und dass interfaces/primary auf eine nicht-existente br0 gesetzt ist, das ist natürlich auch nicht so, wie’s sein soll.

Welche Univention-Version hat der Server?

Haben Sie den neu aufgesetzt oder von einer älteren Version hochgezogen? Falls letzteres, was war die erste Version, die installiert war?

Was ist die Ausgabe der folgenden Befehle:

  • ucr search --brief '^version/'
  • ucr search --brief uvmm/kvm/bridge
  • ucr search --brief umc/modules/setup/network

Der Server wurde ursprünglich mit UCS 4.1 installiert, geupdatet auf 4.2 vor kurzem. Seit dem auch erst UVMM + VM installiert. Ja und wenn ich die virbr0 als Interface bei Geräte in der VM eintrage, funktioniert das zunächst auch im Gegensatz zu br0, wo er direkt meckert, dass es kein br0 gibt. Habe dann jedoch keine Internetverbindung.
Zudem habe ich gerade gesehen, dass in der Datei /etc/network/interfaces


auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.2.56
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 192.168.2.1

eingetragen ist. Dadurch wird wohl auch nichts verändert, wenn ich es umstelle über die UMC.

Hier die Ausgaben:

root@ucs:~# ucr search --brief '^version/'
version/erratalevel: 10
version/patchlevel: 0
version/releasename: Lesum
version/version: 4.2
root@ucs:~# ucr search --brief uvmm/kvm/bridge
uvmm/kvm/bridge/autostart: no
uvmm/kvm/bridge/interface: 
root@ucs:~# ucr search --brief umc/modules/setup/network
umc/modules/setup/network: <empty>

Hallo, das virbr0 sieht in der Tat komisch aus, wovon wurde das angelegt?

Normalerweise sollte nach der Installation von UVMM eine neue Bridge br0 angelegt sein, die das Interface eth0 einbindet. Wenn die anderen Bridges also nur zum Test da sind würde ich sie entfernen, so dass es nur ethX Geräte, das docker0 Interface und lo gibt.

Die erneute Einrichtung der Bridge für KVM kann dann durch den Aufruf /usr/lib/univention-virtual-machine-manager-node-kvm/ucs-kvm-setup-bridge getriggert werden, genau das wird auch bei der Installation der KVM App gemacht (univention-virtual-machine-manager-node-kvm.postinst). Falls die Bridge br0 dann nicht erstellt wurde, einmal Ausgaben des Aufrufs, gerne auch mit dem Parameter -v, hier posten.

Das ist logisch, weil die einzige NIC, die in der Bridge ist, nicht verkabelt ist (das sagt das DOWN in der Ausgabe von virbr0-nic).

Eine saubere Konfiguration sähe so aus, dass:

  1. die virbr0-nic entfernt wird (zumindest aus der Bridge virbr0 sollte sie heraus genommen werden),
  2. die eth0 in die Bridge virbr0 aufgenommen wird,
  3. das Hauptinterface auf virbr0 festgelegt wird (über die UCR-Variable interfaces/primary)
  4. die Bridge virbr0 dann auch die IP-Adresse bekommt, die der Server in Summe haben soll (vermutlich also diejenige, die aktuell eth0 hat).

Anschließend können Sie das Interface virbr0 in der Konfiguration der virtuellen Maschinen verwenden.

EDIT: Die Hinweise von Herrn Damrose sind diejenigen, denen Sie folgenden sollten. Damit wären Sie dann wieder nahe an der Standardkonfiguration. Man kann sicherlich auch mit virbr0 weiterarbeiten, aber je standardisierter, desto besser.

Woher vibr0 herkommt kann ich nicht sagen, hatte mich auch gewundert als ich es gesehen habe.

Soweit vielen Dank für die Hilfe, ich werde die Vorschläge gleich mal umsetzen und Feedback geben.

Habe die beiden Bridges gelöscht.
Dann ferade doch noch was kurioses festgestellt, habe ein Vermutung aber ich frage lieber erst nach:
Folglich sind die Einträge in der UCR zu sehen: Darin ist br0 anscheinend richtig eingestellt, oder?

Zusätzlich steht in interfaces/primary ebenfalls br0…

In der /etc/network/interfaces Datei steht allerdings:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.2.56
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1

Ebenso steht in der Ausgabe von ip address show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 90:1b:0e:ac:3b:c0 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.56/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::921b:eff:feac:3bc0/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 90:1b:0e:ac:7d:08 brd ff:ff:ff:ff:ff:ff
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:11:fa:66:a0 brd ff:ff:ff:ff:ff:ff
inet 172.17.42.1/16 scope global docker0
valid_lft forever preferred_lft forever

Irgendwas ist da nicht richtig, bevor ich allerdings wieder rumprobiere und mich wieder aussperre habt ihr doch sicher einen Tip was hier falsch gemacht wurde?

Soweit noch mal vielen Dank!

Die interfaces sollte in der Tat iface br0 sein und ein paar Einstellungen wie bridge_ports enthalten.

Führen Sie mal ucr commit /etc/network/interfaces aus. Wie sieht die danach aus?

Ah dachte ich es mir doch und so einfach kann es gehen. Tatsächlich waren hier falsche Werte eingetragen. Jetzt steht es auf

auto br0
iface br0 inet static
address 192.168.2.56
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
bridge_fd 0
bridge_ports eth0

Versuchen Sie’s nun mal mit einem Reboot. Wie sehen Interfaces & Bridges danach aus? Also Ausgabe von ip a und brctl show.

So siehts nach dem Neustart aus:

root@ucs:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 90:1b:0e:ac:3b:c0 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 90:1b:0e:ac:7d:08 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 90:1b:0e:ac:3b:c0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.56/24 brd 192.168.2.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::921b:eff:feac:3bc0/64 scope link 
       valid_lft forever preferred_lft forever
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:32:de:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:32:de:32 brd ff:ff:ff:ff:ff:ff
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:b2:f5:c5:9f brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever
root@ucs:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.901b0eac3bc0	no		eth0
docker0		8000.0242b2f5c59f	no		
virbr0		8000.52540032de32	yes		virbr0-nic

Wunderbar funktioniert jetzt alles, es wurde zwar wieder virbr0 angelegt, aber in den Geräten bei VM funktioniert alles einwandfrei auch wenn ich br0 als Bridge setze. Habe jetzt auch 2 IP-Adressen und Internetverbindung.

Ich bedanke mich herzlich, hat mir viel Zeit gespart! Danke!

Mastodon