Starting qemu-system-x86_64 with -nic user,ipv6=off,hostfwd=tcp::9022-:22
With only the lo interface (with 127.0.0.1 associated to it) present on the host, the vm will start, but any daemon trying to allocate port 22 will hang. e.g. inside vm: #systemctl start sshd will just hang until killed, and nothing interesting will show up on logs.
If I have any other interface up on the host before starting qemu, then the vm also starts, but port 22 can be assigned just fine. And ss will show:
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))
What is causing this issue? The qemu host process is not trying to associate it with any of the IPs that depends on the missing interfaces.
I am not using kvm. here's the full command:
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: More focus on systemd
I think this is exclusively a systemd issue. ...sigh.
starting sshd manually, using the exact same exec systemd should have been using, works just fine! sshd defaults to listen 0.0.0.0,
also, this is all using standard distribution files. Nothing custom.
$ 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
(commented stuff was to try to unclock systemd, no luck)
also, this is inside a vm with user network, so it always have a valid network from the vm point of view:
$ 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
and of course, the solution was that systemd was just !(*@&#!@ waiting for ntp, for forever!
as soon as i get online:
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.
Nice! zero visibility on something that would impact me forever in case that ntp host wasn't reachable or something... still unsure what is tying those things.
$ systemctl show sshd
...
After=sysinit.target systemd-journald.socket pacman-init.service basic.target system.slice
...i guess it is because someone attached pacman-init.service to it?! even though it will be skipped as it only run to sign the keys at first boot?! even systemctl list-dependencies sshd would show everything either all green or skipped. no warnings. What a disgrace of experience.
