Kann man einer VM unter KVM/libvirt ein virtuelles Netzwerkinterface zuweisen?

[NoobOfLinux]

Guten Tag liebe Gemeinde,

ich bastel schon einige Zeit an virtuellen Maschinen über KVM/libvirt rum, komme aber nicht so recht an das Ergebnis heran, was ich mit gesteckt hatte. Ich möchte auf einer VM einen Webserver für's Intranet einrichten, der sich aber (im Netzwerk) wie ein physischer Host verhält, also als wenn ich vor einem realen Rechner sitzen würde mit allen Möglichkeiten und notwendigen Konfigurationsschritten.

Bisher soweit bin ich gekommen: Entweder ich realisiere das ganze nur über KVM/QEMU mittels tun/tap interfaces und lasse die Vorteile, die libvirt mitbringt (autostart der vm über den daemon) hinten runter fallen oder ich habe in meinem Hostsystem eine bridge hängen, die per NAT die VM mit dem Netz verbindet, wodurch die VM in einer anderen IP Range hängt und (wahrscheinlich durch das NATing) ICMP-Pings vom Netz zur VM nicht durchlässt.

Hat jemand eine Idee, wie man der VM einfach eine virtuelle Netzwerkkarte zuweisen kann, ohne dabei auf libvirt zu verzichten? Mich macht es etwas kirre, wenn ein Betriebssystem die Konfiguration auf eine statsiche IP bekommt und trotzdem die DHCP-Konfiguration aus der ../libvirt/qemu/network/default.xml greift, zumal sich das ganze wehrt, mit der ip-range im Bereich des physischen Netzes zu gelangen.

Mich würde eure Meinung dazu interessieren. Danke!

[jph]

ich habe in meinem Hostsystem eine bridge hängen, die per NAT die VM mit dem Netz verbindet, wodurch die VM in einer anderen IP Range hängt

Genau das macht eine Bridge nicht: sie macht kein NAT. Alle Devices sind im gleichen Netz.

[NoobOfLinux]

ich habe in meinem Hostsystem eine bridge hängen, die per NAT die VM mit dem Netz verbindet, wodurch die VM in einer anderen IP Range hängt

Genau das macht eine Bridge nicht: sie macht kein NAT. Alle Devices sind im gleichen Netz.

Hier mal ein Auszug aus der default.xml die als Netzwerk-Konfig dient:

Code: Alles auswählen

<network>
  <name>default</name>
  <uuid>xxxx-xxxx-xxxx-xxxx</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.100' end='192.168.122.254' />
    </dhcp>
  </ip>
</network>

Die VM hat dann irgendeine IP im Bereich von 192.168.122.0 aber mein physisches Netz ist 192.168.0.0.

[jph]

Ja, da wird mit den Begriffen irreführend umgegangen. Es gibt eine virtuelle Bridge, an die alle VM angeschlossen sind, diese Bridge selbst ist aber per NAT mit deinem „echten“ Netzwerk verbunden. Das hat den Vorteil, dass das ganze im Userspace und ohne Änderungen an der Konfiguration des Rechners funktioniert.

Was du zu suchen scheinst, ist eine Bridge, an die dein Netzwerkgerät und die VM angeschlossen werden. Das Vorgehen dafür wird hier beschrieben: https://wiki.libvirt.org/page/Networkin ... vice.22.29. Ich hab’s mangels Bedarf nicht ausprobiert, aber wenn du es tust, dann berichte hier doch bitte von deinen Erfahrungen.

Im verlinkten Dokument wird auf https://wiki.debian.org/BridgeNetworkConnections, damit habe ich die LXC-Container auf meinem Serverlein im Keller mit der Außenwelt verbunden.

[NoobOfLinux]

Danke dir für die Antwort!

Ich schau' mir das heute mal genauer an und gebe ein feedback.

[NoobOfLinux]

Nachdem ich mir die Artikel genauer durchgelesen hatte, versuchte ich, mit dem passtrough-modus das Interface enp2s0 einzubinden, was mir nicht gelang. Allerdings gelang es mir mittels virt-manager ein MacVTap Interface zu erzeugen und per passthrough an die VM durch zureichen. DIe VM verhielt sich daraufhin auch so, wie ich es wollte. Nachdem ich testweise eine zweite VM erstellt hatte, zeigte sich allerdings, das nur eine VM startete. Die darauf folgend gestartete VM versagt den Dienst mit folgender Fehlermeldung:

Fehler beim Starten der Domain: error creating macvtap interface macvtap1@enp2s0 (52:54:00:d0:27:9b): Das Argument ist ungültig

Anscheinend zeigt die Konfiguration beider VM's auf die selbe MacVTap Schnittstelle. Ich werde das nochmal Testen, indem ich eine zweite MacVTap manuell erstelle und bei der zweiten VM einbinde. Wenn der Fehler nicht weiter besteht, bin ich erstmal zufrieden. Das Resultat werde ich hier natürlich der Allgemeinheit zur Verfügung stellen.

Vom modus passtrough inspiriert, versuchte ich nun noch etwas anderes, was allerdings zu weiteren Fragen geführt hat. Ich wollte händisch in der /etc/networking/interfaces ein virtuelles Interface erzeugen, was mir aber nicht gelang. Erkennt jemand in den nachfolgenden Handlungsschritten einen Fehler?

Code: Alles auswählen

cat /etc/networking/interface
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

Daraufhin hab ich erstmal NetworkManger lahm gelegt

Code: Alles auswählen

update-rc.d network-manager disable
update-rc.d networking enable

und mal eine ganz rudimentäre Konfiguration hinterlegt

Code: Alles auswählen

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto enp2s0
iface enp2s0 inet dhcp

auto enp2s0:1
iface enp2s0:1 inet static
address 192.168.0.248
netmask 255.255.255.0
gateway 192.168.0.1

was mir dann wie folgt beim reset von /etc/init.d/networking restart quttiert worden ist

Code: Alles auswählen

Jan 01 15:17:47 saiga ifup[1609]: ifup: failed to bring up enp2s0:1
Jan 01 15:17:47 saiga systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE

Wenn ich den Block von enp2s0:1 auskommentiere, läuft es.

Hab ich irgendwo einen Typo drin oder fehlt da nochwas?
Ist seit dem Updates im Bereich Networking (Benennung der Interfaces, SysVInit vs. System.d ect.) diese Art der Erstellung von virtuellen Interfaces weggefallen?
Danke schon mal für die Hilfe!

/EDIT
Gesundes neues Jahr!

[NoobOfLinux]

So, erstmal ein Nachtrag zum Post von 01.01.2021 15:46:01

Nachdem ich mir die xml Definitionen der VM's angesehen habe, stellte sich folgendes heraus:

Code: Alles auswählen

<interface type='direct'>
      <mac address='52:54:00:d0:27:9b'/>
      <source dev='enp2s0' mode='passthrough'/>
      <model type='virtio'/>
      ...

Die Konfiguration ist bei beiden VM's hinterlegt. Jetzt wird das physische Netzwerkinterface durchgereicht. Ich dachte noch zwischenzeitlich, es liegt an der gleichen MAC Adresse, die eingetragen war. Paradox ist hier, dass beim Start der zweiten VM (mit geänderter MAC) über virt-manager eine Fehlermeldung angezeigt wird, die als Fehler die MAC der ersten VM angibt. Anscheinend gibt es auch eine gewisse Latenzzeit, bis die VM das physische Netzwerk für den Host blockiert.

Mir eröffnet sich zwar nicht so richtig, wieso die Einstellungen wären der Installation abgewandelt worden sind und wieso virt-manager eine Konfiguration (MAC) lädt, die in der zugrunde liegenden libvirt VM Definition nicht existiert, aber EDV ist ja auch das Ende der Vernunft und ich nehm's erstmal so hin. Hilft mir nur in der Sache relativ wenig.

[jph]

Hm. Mit Passthrough anstelle einer Bridge hast du den m.E. kompliziertesten Weg gewählt. Gab es einen Grund dafür?

[NoobOfLinux]

Jein ... eigentlich besteht kein Grund aber ich kann mir Vorstellen, dass es einen Geben könnte.

Hintergrund: Ich will auf der VM bisschen was ausprobieren, was in die Richtung Netzwerk geht. Da ich davon ausgehe, dass Fehler gemacht werden, wollte ich es das ganze so "nativ" wie möglich halten. Netzwerkfehler zu bestimmen, bekomme ich "nativ" am Rechner schon einigermaßen hin aber wenn das ganze noch von hinten durch die Brust ins Auge gedacht werden muss, wirds schwierig mit dem Nachvollziehen.