☰

Warum kann QEMU das Host-Only-Netzwerk beim Loopback nicht starten, wenn auf dem Host kein anderes Netzwerk vorhanden ist?

tag-icon • tag-icon networking systemd qemu systemd-service
Warum kann QEMU das Host-Only-Netzwerk beim Loopback nicht starten, wenn auf dem Host kein anderes Netzwerk vorhanden ist?

Beginnen qemu-system-x86_64mit-nic user,ipv6=off,hostfwd=tcp::9022-:22

Wenn nur die loSchnittstelle (mit der 127.0.0.1zugehörigen Schnittstelle) auf dem Host vorhanden ist, wird die VM gestartet, doch jeder Daemon, der versucht, Port 22 zuzuordnen, bleibt hängen. Beispielsweise bleibt innerhalb der VM: #systemctl start sshdeinfach hängen, bis es beendet wird, und in den Protokollen wird nichts Interessantes angezeigt.

Wenn ich vor dem Start von QEMU eine andere Schnittstelle auf dem Host aktiv habe, startet die VM zwar auch, aber Port 22 kann problemlos zugewiesen werden. Und es sswird angezeigt:

Netid   State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port  Process
tcp     LISTEN 0      1       0.0.0.0:9022        0.0.0.0:*          users:(("qemu-system-x86",pid=9035,fd=12))

Was verursacht dieses Problem? Der QEMU-Hostprozess versucht nicht, ihn mit einer der IPs zu verknüpfen, die von den fehlenden Schnittstellen abhängen.

Ich verwende kein KVM. Hier ist der vollständige Befehl:

qemu-system-x86_64 -machine pc,vmport=off,mem-merge=off,dump-guest-core=off,kernel-irqchip=split -smp 4 -m 1G,slots=4,maxmem=8G -name vm -monitor tcp:127.0.0.1:9023,server,nowait -msg timestamp=on,guest-name=on -rtc base=utc,clock=host,driftfix=none -pidfile .vm_started -daemonize -no-reboot -D .vm.log -nic user,id=n1,ipv6=off,hostname=vm,hostfwd=tcp::9022-:22,hostfwd=tcp::8000-:8000 -boot c -drive file=linux-x86.qcow2,index=0,media=disk,snapshot=off,format=qcow2;

edit: Mehr Fokus auf systemd

Ich denke, das ist ausschließlich ein systemd-Problem. ...seufz.

Das manuelle Starten von sshd mit genau demselben Exec, das systemd hätte verwenden sollen, funktioniert einwandfrei! sshd hört standardmäßig auf 0.0.0.0,

außerdem werden hier standardmäßige Distributionsdateien verwendet. Nichts Benutzerdefiniertes.

$ cat /lib/systemd/system/sshd.service 
[Unit]
Description=OpenSSH Daemon
#Wants=sshdgenkeys.service
#After=sshdgenkeys.service
#After=network.target

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

(der Kommentar war, zu versuchen, systemd zu enttakten, kein Erfolg)

außerdem befindet es sich innerhalb einer VM mit Benutzernetzwerk, sodass es aus Sicht der VM immer ein gültiges Netzwerk hat:

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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 fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    inet 10.0.2.15/24 metric 1024 brd 10.0.2.255 scope global dynamic eth0
       valid_lft 84976sec preferred_lft 84976sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

und die Lösung bestand natürlich darin, dass systemd einfach !(*@&#!@ ewig auf NTP wartete!

sobald ich online bin:

Apr 23 15:58:16 archlinux systemd[1]: Reached target System Time Synchronized.
Apr 23 15:58:16 archlinux systemd[1]: Started Refresh existing PGP keys of archlinux-keyring regularly.
Apr 23 15:58:16 archlinux systemd[1]: Started Daily verification of password and group files.
Apr 23 15:58:16 archlinux systemd[1]: Reached target Timer Units.
Apr 23 15:58:16 archlinux systemd[1]: Initializes Pacman keyring was skipped because of an unmet condition check (ConditionFirstBoot=yes).
Apr 23 15:58:16 archlinux systemd[1]: Started OpenSSH Daemon.

Nett! Keine Sichtbarkeit bei etwas, das mich für immer beeinträchtigen würde, falls der NTP-Host nicht erreichbar wäre oder so ... immer noch nicht sicher, was diese Dinge verbindet.

$ systemctl show sshd
...
After=sysinit.target systemd-journald.socket pacman-init.service basic.target system.slice

... ich schätze, es liegt daran, dass jemand pacman-init.service daran angehängt hat?! obwohl es übersprungen wird, da es nur ausgeführt wird, um die Schlüssel beim ersten Start zu signieren?! systemctl list-dependencies sshdwürde sogar alles entweder grün oder übersprungen anzeigen. keine Warnungen. Was für eine Schande der Erfahrung.

Antwort1

Das Problem war, dass systemd mich manipuliert hat. Es hat nichts getan, da es auf eine Abhängigkeit gewartet hat, aber das wurde in keinem Protokoll angezeigt. Es wurde auch nicht angezeigt, dass die Abhängigkeit, auf die es gewartet hat, eine Abhängigkeit von meinem Dienst war.

Umgezogen nachhttps://unix.stackexchange.com/questions/743795/how-to-get-visibility-on-systemd-unit-lifecycle

verwandte Informationen