Libvirt und erreichbar von aussen

[RobertS]

So langsam geb ichs auf.
So schön und komfortabel libvirt und der Virt-manager auch sind, am Netzwerk verzweifel ich. Ich bekomm einfach keinen Zugriff in die VM rein. Noch nicht einmal vom Host aus.
Würde sich irgendwo wenigstens eine grundsätzliche Doku finden sähe ich ja noch ne Chance. Alles was aufzutreiben ist verweist auf Besonderheiten von Kernel 2.6, Einträge in der /etc/network/interfaces, die dann aber die einzige Netzwerkkarte im Host belegen und bei einem headless Betrieb eher suboptimal sind, oder sonstige Werkzeuge die seit langer Zeit nicht mehr zum Standard gehören. Es sollte doch möglich sein einen Webserver, oder ähnliches, in einer Versuchs VM zu betreiben ohne gleich das Komplettsystem zu zerschießen.

[TomL]

Ich bekomm einfach keinen Zugriff in die VM rein. Noch nicht einmal vom Host aus.

Definiere mal mit einfachen Worten 'Zugriff'... was das bedeutet, was unternommen wurde, was am Ende überhaupt rauskommen soll und was wann wobei wie in welcher Reihenfolge passiert.

[RobertS]

Rauskommen soll ein Testserver, Spielwiese.
Dafür muß die VM leider von einem anderen Rechner, oder auch vom Host aus erreichbar sein.
Ein ssh VM würde schon mal genügen für den Anfang. Ja ssh ist installiert.

[TomL]

Wie ist auf dem Host das Netzwerk für die VM eingerichtet? Via NAT oder via Bridge?

[RobertS]

Libvirt richtet das mit Nat ein. Aber eben mit iptables und eigenem dhcp. Vor einer Bridge schreck ich ein wenig zurück nachdem ich mich damit schon mal ausgesperrt hab und die Kiste nur eine Netzwerkkarte hat. Der Versuch eine virtuelle Karte hinzuzufügen und die mit der virbr0 zu verbinden wirft einen UTF-8 Error. Weitere Fehlermeldung unterbleibt leider.

[TomL]

Ok, das ist insofern ein wenig tricky, weil die VM eine IP aus einem völlig anderen Subnet innehat... also im weitesten Sinne läuft die VM in einem isolierten Netzwerk. Der Zugang zu dieser VM via SSH funktioniert in dem Fall über die IP des Hosts mit einem anderen Port anstatt dem üblichen 22, und im folgenden mit sowas wie einer Portweiterleitung bzw. -Forwarding dieses Ports auf den Port 22 der VM. Das kann man einrichten, um die VM SSH-Seitig zu erreichen, aber ich empfinde das als keine gute Lösung. Lokal vom Host ist die VM ja direkt und geradezu perfekt über den Virtviewer zu erreichen - sofern der GraphicsType der VM via Spice konfiguriert ist.

Wenn man die VM im Netz mit einer eigenen IP erreichen will, also quasi als eigenständiger LAN-Client der auch perfekt via SSH zu erreichen ist, dann funktioniert das über eine Bridge. Aber an dem Punkt würde ich mich ausklinken, weil ich in meinen Ansichten zur Netzkonfiguration eher ein wenig radikal-puristisch eingestellt bin. Das heisst, ich verzichte generell auf diesen ganzen Bit-Müll wie Networkmanager, DHCPD, /etc/network/interfaces oder sonstige automatische Netzwerkskonfiguration. Das ist mir alles zu störanfällig, insofern wird das Netzwerk bei uns auf allen Maschinen sehr low-level-mäßig mithilfe spezieller eigener systemd-Service-Units unmittelbar gestartet und eingerichtet. So ansatzweise habe ich das hier [1] und alternativ für ein anderes Projekt [2] hier mal beschrieben. Nur kann man das leider nicht so leicht vermitteln, weil eben die automatismen und entsprechende Erwartungshaltungen der Standard sind. Sorry....

[1] viewtopic.php?p=1217816#p1217816
[2] http://www.thlu.de/openvpn_bridging.html#add

[RobertS]

Dazu würde mich folgendes interessieren:

• mit einer Netzwerkbrücke, ist der Host dann auch noch erreichbar?
• klappt das auch mit nur einer Nerzwerkkarte?

Meinen Network Manager lieb ich auf dem Laptop, der ist aber auch mal unterwegs und hat mit verschiedenen Netzwerken zu tun.
Der Host für die Versuchs VM bekommt per networkd seine Konfiguration, das NAS, auf dem liegen die VM Images, ist statisch über /etc/network/interfaces konfiguriert.
Eines meiner Probleme ist leider daß ich schon nicht ganz durchblicke wie der Virt-manager die Konfig umsetzt. Ich weiß also nicht einmal an welchen Stellen ich die Konfigurationsdateien suchen soll.
Aus dem Grund komm ich auch mit gut gemachten Blogartikeln ala: "Servervirtualisierung mit Debian Lenny" nicht weiter.

Mit deinen beiden Links bin ich jetzt wohl mal ne weile beschäftigt, danke dafür.

[willy4711]

Vielleicht hilft es ja, wenn ich das mal in Virualbox zeige. Ob das auf den Virt- Manager übertragbar ist ? K.A.
In der VM ----> NAT
Dann kann man Im Virtualbox-Manager eine Port-Weiterleitung einrichten:
Und zwar so:

Code: Alles auswählen

Host IP: 127.0.0.1
Host Port: 2222
Guest IP: 10.0.2.15
Guest Port: 22

Starten, und vom Host aus:

Code: Alles auswählen

$ ssh -p 2222 willy@127.0.0.1
The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established.
ECDSA key fingerprint is SHA256:43s+JPezjS1BToQEf9WSNaEnd5YpCrGQCVMOt3BegLw.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts.
willy@127.0.0.1's password: 
....
.....
Last login: Sat Jun  6 01:04:49 2020 from 192.168.0.40
willy@debian:~$ inxi -F
System:    Host: debian Kernel: 5.6.0-2-amd64 x86_64 bits: 64 Console: tty 1 
           Distro: Debian GNU/Linux bullseye/sid 
Machine:   Type: Virtualbox System: innotek product: VirtualBox v: 1.2 
           serial: <superuser/root required> 
           Mobo: Oracle model: VirtualBox v: 1.2 serial: <superuser/root required> BIOS:

Ferddig

Bildchen dazu:

[TomL]

Dazu würde mich folgendes interessieren:
mit einer Netzwerkbrücke, ist der Host dann auch noch erreichbar?

Ja, damit sind es zweit autonome 'Geräte' im LAN, jeweils mit einer eigenen LAN-IP, ein physisches, ein virtuelles Gerät

klappt das auch mit nur einer Nerzwerkkarte?

Ja sicher, deswegen ja die Bridge ... zu einem virtuellen NIC für die VM

[novalix]

Ja, damit sind es zweit autonome 'Geräte' im LAN, jeweils mit einer eigenen LAN-IP, ein physisches, ein virtuelles Gerät

Ergänzend zur Illustration:

Code: Alles auswählen

ip a (geschnitten)
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:24:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.yyy.183/24 brd 192.168.1.255 scope global dynamic eth0
    ...
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.xxx.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: vethHAKUF7@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UP group default qlen 1000
    ...

eth0 = physische NIC
virbr0 = virtuelle NIC, Gateway für die VM-Clients
virbr0-nic = weiss ich grad nicht
veth... = Client Interface

Leider habe ich auf dem Rechner durch einen Blackout im Stadtviertel meine History verloren, kann Dir also nicht mehr sagen, wie genau ich das eingerichtet habe.

In dem Netz lief mal eine KVM-Instanz und einige LXC. Die KVM-Instanz ist jetzt auch ein Container, deshalb wird KVM/Qemu gar nicht mehr gestartet.

Die Gäste sind aber alle vom Host aus erreichbar. Wenn Du von anderen Maschinen im LAN auf die Gäste zugreifen möchtest, musst Du Forwarding zwischen eth0 und virbr0 einrichten.

[RobertS]

… kann Dir also nicht mehr sagen, wie genau ich das eingerichtet habe.

Genau das wäre aber interessant. Allmählich glaube ich das geht mit Debian, oder mit Bullseye, einfach nicht.
Oder man muß sich die Infos aus dem Sourcecode ziehen.
Oder es ist für Debian einfach nur nicht Dokumentiert oder etwas veraltet. Also 2010 oder gar Lenny.
Ein wenig spiel ich noch rum, aber langsam schwindet der Glaube daß das noch was wird. Der debianway fällt einem ab und an dann doch auf die Füße.

[TomL]

Allmählich glaube ich das geht mit Debian, oder mit Bullseye, einfach nicht.

Natürlich geht das mit Debian Buster... und aus den Sourcen muss man überhaupt nichts ziehen. Und soweit es das "weiss ich grad nicht-NIC" aus novalix Posting angeht, das braucht man nicht. Erschwerend bzw verwirrend ist, dass er unterschiedliche Subnetze (192.168.1.0/24 und 192.168.122.0./24) verwendet, weswegen ich jetzt nicht weiß, ob die VMs wirklich reguläre LAN-Clients sind... oder nur NAT-Clients des Hosts.

Das erste Problem ist, dass es haufenweise veraltete Dokumentationen im WWW gibt. Bei manchen Sachen wäre tatsächlich besser, wenn das Web mal was vergessen würde.

Das weitere Problem ist, dass Du konkurrierende Netzwerkdienste ausschalten muss bzw. solltest. Der Netzwerkmanager, systemd-networkd, dhcpd, ifup-Services, /etc/interfaces... das sind alles Stellen, wo sich irgendein Tool auf eher verdeckter Weise mit dem Herstellen einer Netzwerkverbindung befasst. Im Regelfall tun diese Programme das mit der Intention benutzerfreundlich zu sein und verlangen absolut und exklusiv zu werkeln. Für die ganzen Standard-Situationen an einem normalen Desktop-PC ist das völlig ausreichend.

Aber ggf. multiple VMs als autonome LAN-Clients auf einem Host als VM-Server ist eben kein Standard-Setup. Da ist es am einfachsten, wenn man den ganzen konkurrierenden Netzwerk-Kram deaktiviert und das Netzwerk selber in eindeutiger Weise etabliert.

[RobertS]

Die Geschichte mit der veralteten Doku ist wirklich ein Problem.
Weitere Stolperfalle, viele Lösungen, auch unter wiki.libvirt.org, funktionieren nur unter qemu:///session, andere nur unter qemu:///system. Steht aber seltenst dabei.
hook scripte von wiki.libvirt.org erfordern root Rechte, die es aber nur bei qemu:///system gibt.
qemu:///system kann dann dafür nicht auf mein NAS schreiben, weil es als root schreiben will.
Alles muß man sich mühsam zusammensuchen und hoffen daß sich Fehler sofort bemerkbar machen und nicht erst später.
Fehlermeldungen ala UTF-8 Fehler in Phyton script Zeile 169 ohne Angabe des Pfades machen es dann nicht einfacher.

[RobertS]

Ok, Zugriff aufs NAS als root per NFS ist erledigt.
Jetzt also alles von vorn mit qemu:///system, und dann mal schauen.

[RobertS]

Es ist schon spannend, eigentlich hab ich den kleinen Rechenknecht, headless Host für die VMs und Spielwiese, gestern ziemlich in Ruhe gelassen. Mal abgesehen von dem üblichen update/full-upgrade, ist eben Bullseye/Sid.
Jetzt kommt die Kiste heute nicht mehr hoch, bzw. kommt schon hoch, aber nicht ins Netz.
Peinlich bei einer Kiste ohne Monitor, und ohne passendem Anschluß für die Monitore die so am Schreibtisch stehen. Einziges Gerät mit HDMI Eingang ist der Fernseher. HDMI KAbel natürlich auch nicht im Haushalt. Die Graka hat aber zum Glück auch DisplayPort, dafür hab ich ein Kabel DP-HDMI. Zum Glück auch lang genug daß in Verbindung mit einem langen Netzwerkkabel das Ganze sich verdrahten läßt.
Der Grund für das Netzwerkversagen ist nun sichtbar.
Plötzlich heißt die Netzwerkkarte nicht mehr enp irgendwas, sondern eth0. WTF? Wo kommt das nun her?
/etc/interfaces ist leer, bis auf lo. Wie schon die ganze Zeit.
Warum heißt plötzlich die Schnittstelle anders?
Das Problem hat sich zwar lösen lassen mit einem zusätzlichen Eintrag in die /etc/systemd/network/60-dhcp.network, aber es bleibt rätselhaft.
Einzige Änderung, an die ich mich erinnere war die Frage zu einer geänderten Konfigdatei von journald, das hab ich entgegen der Empfehlung mit Y beantwortet.
Netzwerkgeschichten waren beim gestrigen Update nicht dabei.