Wie muss ich für eine VM das Netzwerk konfigurieren, um eine Verbindung zwischen Host und Guest aufbauen zu können und Zugriff zum Web zu haben?
:
Bearbeitet durch User
Mit oder ohne libvirt? 2 unabhängige Netze für die 2 dinge, oder alles im gleichen, oder was anderes? Gebridged oder genatted?
Uhu U. schrieb: > Wie muss ich für eine VM das Netzwerk konfigurieren, um eine Verbindung > zwischen Host und Guest aufbauen zu können und Zugriff zum Web zu haben? Nimm für den Einstieg virt-manager. Das ist eine GUI und recht einfach zu bedienen. Virsh + xml-Dateien zur Konfiguration ist für den Anfang zu kompliziert.
Angehängte Dateien:
-
Damit_auch_nicht.png
12 KB -
Damit_geht_es_nicht.png
18 KB
John Doe schrieb: > Nimm für den Einstieg virt-manager. Das ist eine GUI und recht einfach > zu bedienen. Den habe ich. Ich bekomme aber keine Verbindung zum Host; Web geht – Anhang 2. Wie bekomme NAT? – Anhang 3
:
Bearbeitet durch User
DPA schrieb: > Mit oder ohne libvirt? > 2 unabhängige Netze für die 2 dinge, oder alles im gleichen, oder was > anderes? > Gebridged oder genatted? Wie macht man es am besten, wenn man Samba-Shares haben will?
Uhu U. schrieb: > Wie bekomme NAT? – Anhang 3 Das default netz scheint deaktiviert zu sein (nach screenshot https://www.mikrocontroller.net/attachment/438362/Damit_auch_nicht.png). Versuch mal:
1 | sudo virsh net-start default |
2 | sudo virsh net-autostart default |
Uhu U. schrieb: > Wie macht man es am besten, wenn man Samba-Shares haben will? Kommt drauf an, wo das share ist, und wer darauf zugreifen können soll. Ist das share auf dem host, und nur die VM soll darauf zugreifen können (In dem fall wäre theoretisch 9p die bessere Option, aber die Sandboxin Einstellungen von libvirt können da ziemlich Probleme machen)? Oder ist das im Netzwerk, und beide sollen darauf zugreifen können? Mit dem virt-manager kenn ich mich persönlich nicht so aus, aber mit libvirt/virsh schon. -- Kurzes Briefing zu Linux, libvirt und Networking: Bei macvtap/direct und host passthrough kannst du ignorieren, die sind vor allem hilfreich, wenn man ein Interface nur in der VM haben will, und für ein paar andere Spezialfälle. Für Client <-> Host Verbindungen sind diese jedenfalls ungeeignet. In libvirt gibt es Netzwerk Configs, die man bei anderen VMs wiederverwenden kann. Diese sind von der VM nud vom Hypervisor unabhängig. Unter virsh editiere ich diese immer mit "virsh net-list/net-define/net-edit/net-destroy/net-start/net-stop/net-autostar t netzwerkconfigname" In den VMs kann man es dann nutzen, mit:
1 | <interface type='network'> |
2 | <source network='netzwerkconfigname'/> |
3 | <model type='virtio'/> <!-- This line is optional. --> |
4 | </interface> |
Man kann so viele definieren, wie man will. Jenachdem kann man auch noch ne mac addresse festlegen, und solches zeug. Libvirt fügt glaub ich automatisch eine hinzu, wenn man sie weglässt. Mann kann die Netzwerkkonfig auch direkt dort eingeben, wen nur eine VM sie hat, indem man stat type='network' nen anderen interface typ nimmt. Die Konfigurationsmöglichkeiten können am Anfan etwas überwältigend sein: https://libvirt.org/formatdomain.html#elementsNICS So ein Interface ist beim Host in den meisten fällen auch mit den ifconfig/ip tools ersichtlich, bzw. hat dort ein Gegenstück. Man hat bei vielen dingen die Wahl, ob man libvirt etwas konfigurieren lässt, oder ob man es selbst anderweitig macht. Es ist hilfreich, Bridges als eine art "Switch" zu betrachten, wenn man ein Interface einer VM darin hat, ist es beim Switch eingesteckt. Man muss noch beachten, dass man den Interfaces in den Bridges keine IPs geben sollte, die verwaltet man anderweitig (statisch in der VM oder per DHCP (optional per Libvirt verwaltet)) und führen sonst zu merkwürdigen Problemen, nur der Bridge kann man eine IP geben, das ist dann, wie wenn der Host darin ein Interface hätte. Ich verwende eigentlich immer ein paar per /etc/network/interfaces erstellte Bridges, in eine davon packe ich das host Ethernet Interface, und konfiguriere dann die Bridge statt diesem, dann hab ich quasi host und einige VMs direkt mit einem meiner LAN Netze verbunden, mein Netzwerk Setup ist etwas speziell, und hier eventuell nicht ideal. Zumindest unter Debian gibt es normalerweise ein default network, sowas wie das hier:
1 | <network> |
2 | <name>default</name> |
3 | <bridge name="virbr0"/> |
4 | <forward mode="nat"/> |
5 | <ip address="192.168.122.1" netmask="255.255.255.0"> |
6 | <dhcp> |
7 | <range start="192.168.122.2" end="192.168.122.254"/> |
8 | </dhcp> |
9 | </ip> |
10 | </network> |
Da hat man eine Bridge virbr0 die von libvirt erstellt wird. Der Bridge wird von libvirt die IP 192.168.122.1/24 zugewiesen. Und libvirt wurde zudem konfiguriert, dort drinn einen DHCP-Server laufen zu lassen, der Adressen im Bereich 192.168.122.2 bis 192.168.122.254 vergibt. Die Adressen sind innerhalb vom neuen Netz 192.168.122.0/24, in dem auch die addresse der Bridge ist, der host weiss deshalb, wie er die IPs in dem Bereich, bzw. die VMs in der Bridge erreichen kann. Es ist wichtig, dass dies kein bestehendes Netz ist. Das <forward mode="nat"/> gibt an, dass traffic für andere Netze per NAT geroutet wird. Wie genau das funktioniert, weiss ich auch nicht, vermutlich per iptables oder so. Mit diesem Setup geht VM->LAN und VM<->Host, aber nicht LAN->VM. Bei VM->LAN wird die Hostadresse verwendet, NAT eben. Das ist vermutlich auch das Setup, das du im Screenshot https://www.mikrocontroller.net/attachment/438362/Damit_auch_nicht.png hast. So nebenbei, virtio Netzwerkinterfaces sind in der regel die schnellsten, wenn der Client die unterstützt, das könnte mann noch optimieren. Falls du nicht willst, dass VM->LAN geht, kannst du das forward rausnehmen. Du kannst auch ne zweite bridge machen, die nur für lokalen Traffic ist, und allerhand anderes. Für ganz spezielle sachen könnte man das Routing sogar von hand mit nem script machen: https://libvirt.org/formatdomain.html#elementsNICSEthernet Zudem gibt es zu allen Aktionen bei VMs und Netzwerken noch hook scripte, mit denen man zusatzzeug tun kann. Falls du eine konkrete Netzwerkarchitektur willst, kann ich dir helfen, die umzusetzen.
DPA schrieb: > sudo virsh net-start default
1 | error: Failed to start network default |
2 | error: internal error: Failed to initialize a valid firewall backend |
Also irgendwas mit der Firewall, aber was? > Kommt drauf an, wo das share ist, und wer darauf zugreifen können soll. Der Share liegt auf dem Host und ein paar VMs sollen darauf zugreifen können. Auch interessant wäre der umgekehrte Weg: Host -> VM-Share. Wichtig wäre erst mal die erste Variante. --- Ich habe bisher meine VMs mit VirtualBox laufen lassen, in folgender Konfiguration, die ich gerne auf qemu/kvm nachbilden möchte: - auf dem Host liegen ein paar Shares, auf die eine W7-VM Zugriff haben soll. Grundidee ist, dass dort wichtige Daten liegen, die beim Backup des Hosts per rdiff-backup mit gesichert werden. (Backups der VMs sind zeitraubender.) - 2 andere VMs haben ihre Daten an Bord - diverse meist Linux-VMs sind mehr oder weniger eine Mischung aus beiden. - Keine VM soll aus dem Web erreichbar sein. Bei VB kann man das einfach so zusammenklicken und schon läufts… Leider hat VB ein ganz großes Manko: wenn man z.B. Docker installiert, ist dessen sehr komfortables USB-Interface abgeklemmt und irgend welche Fehlermeldungen gibts nicht – es geht einfach nicht mehr. Der Grund dafür scheint qemu/kvm zu sein, das mit Docker natürlich mit installiert werden muss. VB ist also, wenn man die Entwicklung dieser Tools auf Linux betachtet, ganz einfach eine Sackgasse… Deine Ausführungen über das Netzwerk muss ich erst mal verdauen – aber schon mal vielen Dank dafür. > Die Konfigurationsmöglichkeiten können am Anfan etwas überwältigend sein Das kann man wohl sagen… Wenn ich mir die Optionswälder der Komponenten ansehe, frage ich mich schon, wie man sich da einen Überblick verschaffen soll. Da sind GUIs, die das betreffende Teil füttern und anzeigen, was das Kommandozeilen-Futter ist, schon ganz hilfreich…
:
Bearbeitet durch User
Uhu U. schrieb: > DPA schrieb: >> sudo virsh net-start defaulterror: Failed to start network default > error: internal error: Failed to initialize a valid firewall backend > > Also irgendwas mit der Firewall, aber was? Das Problem hatte ich leider noch nicht, da bin ich jetzt auch etwas überfragt. Nach StackOverflow muss wohl eines der *tables Programme und dnsmasq installiert werden (dnsmasq aber eventuell disablen), aber ob es das ist, weiss ich nicht: https://superuser.com/questions/1063240/libvirt-failed-to-initialize-a-valid-firewall-backend#answer-1360773 Vielleicht ist es auch irgend eine fehlende systemd unit Abhängigkeit, fehlender Kernelsupport für *tables, oder sonst irgendwas, schau mal, ob das *tables program funktioniert. Vielleicht findest du ja in den libvirt Logs auch noch hinweise. Uhu U. schrieb: > Der Share liegt auf dem Host und ein paar VMs sollen darauf zugreifen > können. > Auch interessant wäre der umgekehrte Weg: Host -> VM-Share. Wichtig wäre > erst mal die erste Variante. Das sollte eigentlich mit dem default netz auch gehen. Das sollte für deinen use-case reichen, sofern man es zum laufen bekommt.
Uhu U. ist offensichtlich in Linux nicht soweit, daß er mit virsh + xml klarkommt. Daher mein Rat oben. @Uhu U.: Versuch zuerst mal, mit dem virt-manager ein neues virtuelles Netzwerk zu erstellen. Also auf dem Reiter "Virtuelles Netzwerk" das "+" anklicken, Namen eingeben und dann die Default-Einstellungen übernehmen oder DHCP abstellen, falls Du das nicht brauchst. Wenn das nicht klappt, hast Du irgendwas auf dem Host falsch konfiguriert. Dann solltest Du die Logs vom System und libvirt hier einstellen.
Achso, beim Virtuellen Netzwerk natürlich noch "Zum physischen Netzwerk weiterleiten" anklicken. Dann hast Du NAT und kannst auf Deinen Samba-Share zugreifen, wenn Du in der VM eine IP aus dem Virtuellen Netzwerk hast.
So, jetzt hat er meine Mint-17 .vdi nach .qcow2 konvertiert – hat schlappe 6½ Stunden gebraucht, mehr als doppelt so lange, wie das Konvertieren von Festplatte nach .vdi. Wenn Quell- und Zielplatte identisch sind, dann dauerts und viel anderes geht auf der Maschine nicht. Aber jetzt zum Netzwerk: ich habe versucht, eins anzulegen – das Schwierigste war, die Stelle im Virtual Machine Manager zu finden, wo man das machen kann –, das ging auch so weit, bis es Ernst werden sollte, dann ist er mir wie gehabt mit
1 | Error creating virtual network: internal error: Failed to initialize a valid firewall backend |
abgeschmiert. Als Lösung habe ich für Arch-Linux gefunden, dass man firewalld installieren soll – das scheint auch für Mint zu gelten. Und nach der Installation funktioniert NAT auf dem selbst angelegten Netzwerk – das ich wohl nicht gebraucht hätte, weil das default-Netz auch gehen sollte. Wo finde ich denn die xml-Beschreibung für mein selbst angelegtes Netz?
Uhu U. schrieb: > Wo finde ich denn die xml-Beschreibung für mein selbst angelegtes Netz? Unter Ubuntu unter /etc/libvirt/qemu/networks/. Du kannst Dir aber auch die xml anzeigen lassen mit virsh net-dumpxml [Dein Netzwerk-Name].
Ok, es ist nur zu hoffen, dass firewalld keine anderweitigen Probleme verursacht. Eigentlich sollte es nicht notwendig sein, aber es ist wohl eine der unterstützten Optionen. Bezüglich der Netwerkkonfigdateien, fie sollten nicht manuell bearbeitet werden. Wenn man z.B. "virsh net-edit" ferwendet, prüft das unter anderem Syntax & schema der Config. Das funktioniert genau gleich wie auch bei z.B. visudo.
Ich kämpfe immer noch mit Samba. Der Scheiß will einfach nicht. Der Host ist per ping vom W7-Guest aus erreichbar, umgekehrt geht nicht. Und plötzlich gehts – warum? Keine Ahnung.
:
Bearbeitet durch User
Gibt es noch eine andere Möglichkeit, im Guest Ordner auf dem Host einzubinden, als mit Samba? Ich betreibe Quicken unter W7 und das funktioniert über die Shared Folders von VirtualBox astrein. Wenn die Datei auf einem Samba-Share liegt, weigert sich Quicken, sie zu öffnen – so ein Quatsch…
Uhu U. schrieb: > Und plötzlich gehts – warum? Keine Ahnung. Reine Spekulation, aber vielleicht wurde die bridge erstellt und Konfiguriert nachdem samba gestartet wurde, falls der samba daemon sich beim Start explizit an die Interfaces bindet, statt überall zu lauschen, und versucht wurde, sich auf die bridge IP zu verbinden, könnte sowas passieren. Oder falls deine bridge und die des default Netze den selben IP Range haben, könnte es ein routing problem, sowas kann sporadische symptome zeigen, und einen in den Wahnsinn treiben. Oder vielleicht war es auch was anderes. Ich würde mal ein paar neustarts versuchen, und nachsehen, ob das jetzt stabil funktioniert, oder nur manchmal. Uhu U. schrieb: > Wenn die Datei auf einem Samba-Share liegt, weigert sich Quicken, sie zu > öffnen – so ein Quatsch… Versuche mal, auf dem windows client einen symlink auf das Netzlaufwerk anzulegen (direkt auf das \\share\, nicht auf den Laufwerksbuchstaben). Geht mit dem mklink befehl (aber ich hab vergessen, welches Flag das richtige war). Das hab ich beim PC meines Faters auch so gemacht. In Windows sind symlinks über ntfs reparse points implementiert, als folge dessen glauben die Programme dann, es wäre ein normales lokales Verzeichniss. Uhu U. schrieb: > Gibt es noch eine andere Möglichkeit, im Guest Ordner auf dem Host > einzubinden, als mit Samba? Der übliche Weg wäre wohl 9p, aber ich weiss nicht ob Windows damit klar kommt. Es gäbe da schon noch andere wege, aber versuch erstmal die Symlink variante.
DPA schrieb: > Der übliche Weg wäre wohl 9p, aber ich weiss nicht ob Windows damit klar > kommt. Das hab ich probiert – geht nicht, die VM startet damit gleich gar nicht. > Versuche mal, auf dem windows client einen symlink auf das Netzlaufwerk > anzulegen (direkt auf das \\share\, nicht auf den Laufwerksbuchstaben). Ich kann zwar den Link anlegen, aber kann ihn noch nichtmal im Explorer öffnen.
:
Bearbeitet durch User
Angehängte Dateien:
-
13-12-_2019_08-21-08.png
85 KB
Uhu U. schrieb: >> Versuche mal, auf dem windows client einen symlink auf das Netzlaufwerk >> anzulegen (direkt auf das \\share\, nicht auf den Laufwerksbuchstaben). > > Ich kann zwar den Link anlegen, aber kann ihn noch nichtmal im Explorer > öffnen. Das muss eigentlich gehen. Ich hab es hier gerade nochmal ausprobiert, siehe Anhang. Es gibt ein paar Dinge, die noch zu beachten sind. Es muss bei mklink die /D Option verwendet werden, und das Linkziel muss eine Freigabe des Shares oder ein Unterverzeichnis dessen sein. Das Share selbst (Dort, wo die Freigaben des Shares angezeigt werden), ist ein Sonderfall, und kann nicht verwendet werden, da dieses kein normaler Ordner ist.
Jetzt läufts endlich, japs. Fehler waren zum einen die Firewall – nachdem ich alle Verbindungen und Interfaces (außer Docker0) von public in die home-Zone verlegt hatte und Samba nochmal neu installiert hatte, ging es. Vielen Dank für die Nachhilfe euch beiden! Ich habe die Share Extension für Caja installiert und kann dort auch Shares einrichten, die sich Caja merkt, aber in /etc/samba/smb.conf hinterlässt das keine Spuren – keine Ahnung, wo der das speichert…
Die komischen Probleme, die ich mit der Installation der alte W7 VM hatte, könnten damit zusammenhängen, dass das eine 32-Bit-Version ist. kvm bietet gar keine 32-Bit x86 mehr an. Es läuft jetzt aber trotzdem ganz ordentlich. Einen 32-Bit Ubuntu-Server 12.04 habe ich nicht ans Netzwerk bekommen, obwohl der unter VB prima läuft.
Uhu U. schrieb: > Einen 32-Bit Ubuntu-Server 12.04 habe ich nicht ans Netzwerk bekommen, > obwohl der unter VB prima läuft. Woran hängt es denn? Fehlt in der VM das Interface? Oder heisst es anders? Oder bekommt die VM keine IP (in diesem fall, eventuell tcp checksum offloading abschalten)?
Angehängte Dateien:
-
NetworkInterfaces.png
30 KB -
VirtualNetworks.png
36 KB
Die VM hat eine statische IP-Adresse. Die Adresse, die für enp5s0 angezeigt wird, ist die vom Host. Intern heißt der NIC eth0.
:
Bearbeitet durch User
Zeig mal besser einen Screenshot der Konfiguration der NIC der VM.
Angehängte Dateien:
-
DokuwikiVM-NIC.png
9 KB
Die hat nur einen. Welches Device Model eingestellt ist, spielt keine Rolle – mit keinem funktionierts. Schon ein ping zum Router oder zum Host scheitert.
1) Wieso steht in dem Screenshot das default netz wieder auf (inactive)? 2) Die Netzwerkinterfaces in Screenshot, sind die wirklich von der VM, oder sind das die vom Host? Es wäre mir neu, das Libvirt statische IPs von Intervaces innerhalb von VMs erkennen könnte, und es ist mir schleierhaft, wie so etwas überhaupt möglich wäre. Aber ich kenne mich mit der GUI eben auch nicht aus, mit der vm config könnte ich mehr anfangen "virsh list" und dann "virsh dumpxml vmidodername ". 3) wie wurde das Intervace in der VM konfiguriert? Könntest du mal die Ausgabe von "ip addr" und "/sbin/route" in der VM posten? 4) In dem Screenshot VirtualNetworks.png sieht man, dass das default Netz die Netzaddresse 192.168.122.0/24 hat, und das die Adressen 192.168.122.2 bis und mit 192.168.122.254 per DHCP vergeben werden. 192.168.122.0 ist die Netzadresse, 192.168.122.1 ist vermutlich die IP der Bridge und das default gateway?, und 192.168.122.255 ist die Broadcast Adresse. Mit anderen Worten, es gibt keine unverbrauchten Adressen im Netz aber ausserhalb des DHCP Ranges mehr. Soeine braucht man aber, wenn man in der VM ein Interface statisch definieren will. Nimmt man eine im DHCP Bereich, könnte der DHCP Server diese sonst an einen anderen vergeben. Nimmt man eine ausserhalb des Netzes, ist die VM unerreichbar. Haben 2 VMs die gleiche, bekommt man Routing Probleme. Man muss das Default Netzwerk hierfür also anpassen. Entweder man passt die Netzadresse an, auf 192.168.122.0/23 (bzw. Netzmaske 255.255.254.0), dann hat man neu 192.168.122.255 bis 192.168.123.254 frei für statische IPs, oder man verkleinert den DHCP Bereich, z.B. auf 192.168.122.2 bis 192.168.122.127, dann hat man 192.168.122.128 bis und mit 192.168.122.254 für statische IPs frei.
Mittlerweile bin ich dahinter gekommen: Die VB-VM hat eine statische IP-Adresse im Netz des Hosts – mit VirtualBox geht das prima, nur mit qemu/kvm natürlich nicht. Ich habe schon ewig mit VMs gearbeitet und hatte einfach statische Adressen vergeben und die in /etc/hosts verdrahtet. So konnte ich ganz einfach mit ssh an die VMs ran. Die VMs waren per Bridge direkt ans reale Host-Netz angeklemmt. Wenn qemu/kvm für die Namensauflösung sorgt und die auch vom Host aus zugreifbar sind, ist mein Problem gelöst, dann können alle VMs mit dhcp laufen. Aber sicherlich gibt es doch eine Möglichkeit, den NIC per Bridge ans Host-Netz zu hängen, aber wie muss man das anfangen?
:
Bearbeitet durch User
Angehängte Dateien:
Anhang: Einstellungen für den NIC auf VB. Das kriege ich nicht mit dem Modell von qemu/kvm zusammen. Aus dem Verhalten würde ich schließen, dass unter VB die VMs, der reale NIC und ein "unsichtbarer" virtueller NIC im Host an einem Switch im Netz des Routers hängen – warum dieses Teil dann Bridge heißt, erschließt sich mir nicht, denn es macht keine Adressumsetzung. Zum Verständnis: Wie kann man dieses Verhalten auf qemu/kvm nachbilden?
Uhu U. schrieb: > Aber sicherlich gibt es doch eine Möglichkeit, den NIC per Bridge ans > Host-Netz zu hängen, aber wie muss man das anfangen? Viele Wege führen nach Rom... Auf die Schnelle halte ich folgendes für die einfachste Lösung für Dich: Du erstellst auf Deinem PC (Host) eine Bridge, dieser fügst Du Deine Netzwerkkarte hinzu. Der Bridge gibst Du dann eine IP, egal, ob per dhcp (vom Router) oder statisch. Den VMs ordnest Du dann mittels virt-manager als NIC die Bridge zu. Wenn Du es auf die empfohlene Art und Weise unter Ubuntu(-Derivaten) machen willst, dann konfiguriere den Host mittels netplan. Ich finde das am übersichtlichsten und mache das daher auch so.
Uhu U. schrieb: > Anhang: Einstellungen für den NIC auf VB. > > Das kriege ich nicht mit dem Modell von qemu/kvm zusammen. qemu/kvm habe kein Modell. Die nutzen die Infrastruktur von Linux. > Aus dem Verhalten würde ich schließen, dass unter VB die VMs, der reale > NIC und ein "unsichtbarer" virtueller NIC im Host an einem Switch im > Netz des Routers hängen – warum dieses Teil dann Bridge heißt, > erschließt sich mir nicht, denn es macht keine Adressumsetzung. Ich versteh Dich nicht ganz und VirtualBox kenne ich nicht. Was zeigen denn
1 | brctl show |
2 | ip l |
3 | ip a |
jeweils an?
Seltsamerweise hinterlässt VB in den Listings überhaupt keine Spuren, egal, ob eine VB-VM läuft, oder nicht. Die bringen wohl alles selbst mit und das wird wohl auch der Grund seine, warum sich VB und qemu/kvm gegenseitig beißen.
Uhu U. schrieb: > Aber sicherlich gibt es doch eine Möglichkeit, den NIC per Bridge ans > Host-Netz zu hängen, aber wie muss man das anfangen? Das kann man schon machen. Auf meinem Server ab ich soeine (und noch ein paar andere) Bridges:
1 | <network> |
2 | <name>lan</name> |
3 | <forward mode='bridge'/> |
4 | <bridge name='br-lan'/> |
5 | </network> |
Kurz: ich habe ein netzwerk namens "lan", welches die bestehende Bridge "br-lan" verwendet, libvit verwaltet kein DHCP oder NAT oder sonst was. (Das XML kann man mit "virsh net-define/net-undefine" einlesen/löschen) Den Rest muss ich etwas abwandeln, weil das bei mir etwas speziell eingerichtet ist. Aber im Grunde genommen hab ich dann in der /etc/network/interfaces:
1 | # The primary network interface |
2 | auto eth0 |
3 | iface eth0 inet manual |
4 | |
5 | auto br-lan |
6 | iface br-lan inet manual |
7 | bridge_ports eth0 |
8 | address 10.60.1.254 |
9 | netmask 255.255.255.0 |
10 | gateway 10.60.1.1 |
11 | |
12 | # Falls statdessen DHCP gewünscht ist, stattdessen das hier nehmen: |
13 | # auto br-lan |
14 | # iface br-lan inet dhcp |
15 | # bridge_ports eth0 |
Das kannst du aber leider vermutlich nicht einfach so übernehmen. Einerseits wirst du andere IPs und Netze haben, andererseits nutze ich Devuan, und das war früher mal, wie man spezifisch unter Debian das Netzwerk fix konfigurierte, aber bei anderen Distros, und möglicherweise auch bei üblichen Debian Installationen heutzutage (bin mir hier nicht sicher), vermutlich nicht (mehr). Systemd hat etwas um Netzwerksachen zu Konfigurieren, und Dinge wie Networkmanager könnten eventuell bei sowas auch Herein funken, und viele Distros machen das immer noch auf ire eigene Art, also musst du erst herausfinden, wie du bei deiner Distro sowas konfigurierst. Oder man macht es in libvirt mit nem hook-script, was nicht unbedingt einfacher ist. Man sieht aber trotzdem gut, wie es funktioniert. Du musst das System eine Bridge anlegen lassen, und das Netzwerkinterface, mit dem du und indirekt auch die VMs aufs Netzwerk zugreifst (bei mir eth0), muss der Bridge hinzu gefügt werden. Ich glaube, dass muss vor dem Starten von libvirt* passieren. Das Interface (bei mir eth0), darf keine IP mehr haben, muss aber up sein. Die Konfiguration (IP, Netzmaske, etc.), die das Interface vorher hatte, muss nun auf die Bridge angewendet werden, in der es ist, sofern der Host noch Netzwerkzugang behalten soll. Noch ein paar Beispielausgaben (leicht angepasst, ein paar Interfaces heissen bei mir etwas anders/sind etwas speziell) von diversen Tools, wie das bei mir aussieht:
1 | root@spider:~# ip addr show br-lan |
2 | 5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 |
3 | link/ether 16:76:b5:44:fd:f1 brd ff:ff:ff:ff:ff:ff |
4 | inet 10.60.1.254/24 scope global br-lan |
5 | valid_lft forever preferred_lft forever |
6 | inet6 fe80::14e6:6dff:fead:c53d/64 scope link |
7 | valid_lft forever preferred_lft forever |
8 | |
9 | root@spider:~# brctl show br-lan |
10 | bridge name bridge id STP enabled interfaces |
11 | br-lan 8000.1676b544fdf1 no eth0 |
12 | vnet1 |
13 | vnet11 |
14 | vnet14 |
15 | vnet16 |
16 | vnet18 |
17 | vnet4 |
18 | vnet5 |
19 | vnet6 |
20 | vnet8 |
21 | vnet9 |
22 | |
23 | root@spider:~# ip addr show eth0 |
24 | 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000 |
25 | link/ether 94:18:82:31:2f:d4 brd ff:ff:ff:ff:ff:ff |
26 | inet6 fe80::9618:82ff:fe31:2fd4/64 scope link |
27 | valid_lft forever preferred_lft forever |
28 | |
29 | root@spider:~# route |
30 | Kernel IP routing table |
31 | Destination Gateway Genmask Flags Metric Ref Use Iface |
32 | default 10.60.1.1 0.0.0.0 UG 0 0 0 br-lan |
33 | 10.60.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan |
Uhu U. schrieb: > Anhang: Einstellungen für den NIC auf VB. > > Das kriege ich nicht mit dem Modell von qemu/kvm zusammen. > > Aus dem Verhalten würde ich schließen, dass unter VB die VMs, der reale > NIC und ein "unsichtbarer" virtueller NIC im Host an einem Switch im > Netz des Routers hängen – warum dieses Teil dann Bridge heißt, > erschließt sich mir nicht, denn es macht keine Adressumsetzung. > > Zum Verständnis: Wie kann man dieses Verhalten auf qemu/kvm nachbilden? Jetzt muss ich zum Verständnis nachfragen: Laut Ausgaben hast Du eine Virtualbox-Bridge, an der drei virtuelle Interfaces hängen, vermutlich von drei VMs. Die Bridge hat eine IP aus einem eigenen /16-Netz. Aus diesem bekommen die VMs dann eine IP zugeteilt? Dazu hast Du zwei virtuelle Bridges, die jeweils ein virtuelles Interface haben. Eine Bridge davon ist die default-Bridge von libvirt unter Ubuntu (virbr0, 192.168.122.1/24). Die andere ist die von Dir eingerichtete. Was Du möchtest: VMs erstellen, die mit einer IP aus dem Netz von enp5s0 (192.168.178.101/24) laufen. Richtig?
John Doe schrieb: > Laut Ausgaben hast Du eine Virtualbox-Bridge, an der drei virtuelle > Interfaces hängen, vermutlich von drei VMs. Die Bridge hat eine IP aus > einem eigenen /16-Netz. Aus diesem bekommen die VMs dann eine IP > zugeteilt? Die VMs unter VB haben alle statische IP-Adressen aus dem Netz, mit dem der Host an den Router angebunden ist.
Daniel A. schrieb: > Das kannst du aber leider vermutlich nicht einfach so übernehmen. > Einerseits wirst du andere IPs und Netze haben, andererseits nutze ich > Devuan, und das war früher mal, wie man spezifisch unter Debian das > Netzwerk fix konfigurierte, aber bei anderen Distros, und möglicherweise > auch bei üblichen Debian Installationen heutzutage (bin mir hier nicht > sicher), vermutlich nicht (mehr). Systemd hat etwas um Netzwerksachen zu > Konfigurieren, und Dinge wie Networkmanager könnten eventuell bei sowas > auch Herein funken Richtig. Unter aktuellem Ubuntu mit systemd empfehle ich den networkd. Den NetworkManager würde ich zumindest deaktivieren, besser gleich deinstallieren. Die Konfiguration dann nicht mehr wie früher über die /etc/network/interfaces sondern über /etc/netplan. Geht über eine YAML-Datei und ist deutlich logischer und aufgeräumter. > Man sieht aber trotzdem gut, wie es funktioniert. Du musst das System > eine Bridge anlegen lassen, und das Netzwerkinterface, mit dem du und > indirekt auch die VMs aufs Netzwerk zugreifst (bei mir eth0), muss der > Bridge hinzu gefügt werden. Ich glaube, dass muss vor dem Starten von > libvirt* passieren. Das Interface (bei mir eth0), darf keine IP mehr > haben, muss aber up sein. Die Konfiguration (IP, Netzmaske, etc.), die > das Interface vorher hatte, muss nun auf die Bridge angewendet werden, > in der es ist, sofern der Host noch Netzwerkzugang behalten soll. Das Interface darf natürlich noch eine IP haben (z.B. fallse es noch in anderen Netzen hängt, die nicht gebridget werden sollen). Braucht aber Uhu U. nicht. Auf die Reihenfolge muss auch nicht geachtet werden, das erledigt die Konfiguration über netplan automatisch. Dort konfiguriert man die Bridge, also welche IP sie bekommt, welches Netzwerkinterface, etc.
Fragen zur Datei netzeinstellungen.txt hier: Beitrag "Re: qemu/kvm: Netzwerkeinrichtung" – ich hab sie farblich markiert als pdf hier angehängt. Wozu haben die Bridges eigene IP-Adressen? Woran erkennt man, wie die Bridges mit dem Hardware-NIC kommunizieren?
Uhu U. schrieb: > Wozu haben die Bridges eigene IP-Adressen? Bridges funktionieren auch ohne IP, genau so wie die Interfaces darin. Sie sind wie Switches. Sie leiten einfach die Pakete zwischen den Interfaces weiter. Die Bridge hat dann aus den selben gründe eine IP und Netzmaske, wie jedes andere Gerät, das an einen Switch angeschlossen ist. Einerseits, damit das Gerät selbst über IP erreichbar ist, und andererseits, damit es weiss, welche anderen IPs über den Anschluss erreichbar sind. Das Bridge Interface repräsentiert dann quasi einen Anschluss vom Host an die Bridge/den Switch selbst. Man könnte das selbe auch erreichen, indem man ein Interface eines veth paares in die Bridge tut, und dem anderen veth Interface eine IP gibt. > Woran erkennt man, wie die Bridges mit dem Hardware-NIC kommunizieren? Die ganzen Tools wie iftop, iptraf, tcpdump, etc. funktionieren bei bridges auch, aber die zeigen meistens nur die Quell und Ziel IPs. "brctl show" ist immer ganz praktisch, um zu sehen, was so alles an den Bridges dran hängt. Ansonsten verhalten sich die Bridges ja immer so ziemlich gleich. Dinge wie NAT und Routing sind dann nichts Bridge spezifisches, das geht bei jeder Art von Interface, und wird über Dinge wie iptables/ebtables/firewalld, route, etc. verwaltet.
Die Beschreibung "Virtual Networking on Linux" https://gist.github.com/mtds/4c4925c2aa022130e4b7c538fdd5a89f hat mir etwas mehr Klarheit gebracht, wer da eigentlich was spielt.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.