☰

当主机上没有其他网络时，为什么 qemu 无法在环回上启动仅主机网络？

tag-icon • tag-icon networking systemd qemu systemd-service
当主机上没有其他网络时，为什么 qemu 无法在环回上启动仅主机网络？

qemu-system-x86_64从...开始-nic user,ipv6=off,hostfwd=tcp::9022-:22

如果主机上仅存在lo接口（与其关联），则虚拟机将启动，但任何尝试分配端口 22 的守护进程都将挂起。例如，在虚拟机内部：将一直挂起直到被杀死，并且日志中不会显示任何有趣的内容。127.0.0.1#systemctl start sshd

如果我在启动 qemu 之前在主机上启用了任何其他接口，则虚拟机也会启动，但可以正常分配端口 22。并ss会显示：

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))

导致此问题的原因是什么？qemu 主机进程未尝试将其与任何依赖于缺失接口的 IP 关联。

我没有使用 kvm。这是完整的命令：

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;

编辑：更加关注 systemd

我认为这完全是一个系统问题。......叹息。

手动启动 sshd，使用与 systemd 完全相同的 exec，运行正常！sshd 默认监听 0.0.0.0，

此外，这一切都使用标准分发文件。没有自定义文件。

$ 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

（评论的内容是尝试解锁 systemd，但没有成功）

此外，这是在具有用户网络的虚拟机内部，因此从虚拟机的角度来看它始终具有有效的网络：

$ 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

当然，解决方案是 systemd 只是 !(*@&#!@ 等待 ntp，永远！

我一上网：

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.

太棒了！如果 ntp 主机无法访问或发生其他情况，那么将永远影响我的事情将一无所知……仍然不确定是什么在将这些事情联系在一起。

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

...我猜是因为有人将 pacman-init.service 附加到它？！即使它会被跳过，因为它只在第一次启动时运行以签署密钥？！甚至systemctl list-dependencies sshd会显示所有内容，要么全部为绿色，要么已跳过。没有警告。真是一次耻辱的经历。

答案1

问题是 systemd 欺骗了我。它什么都没做，因为它在等待依赖项，但它没有在任何日志中显示这一点。它也没有显示它正在等待的依赖项是对我服务的依赖项。

搬去https://unix.stackexchange.com/questions/743795/how-to-get-visibility-on-systemd-unit-lifecycle

相关内容