☰

¿Por qué qemu no puede iniciar la red de solo host en loopback cuando no hay otra red en el host?

tag-icon • tag-icon networking systemd qemu systemd-service
¿Por qué qemu no puede iniciar la red de solo host en loopback cuando no hay otra red en el host?

Empezando qemu-system-x86_64con-nic user,ipv6=off,hostfwd=tcp::9022-:22

Con solo la lointerfaz (con 127.0.0.1asociada a ella) presente en el host, la máquina virtual se iniciará, pero cualquier demonio que intente asignar el puerto 22 se bloqueará. por ejemplo, dentro de vm: #systemctl start sshdsimplemente se bloqueará hasta que se elimine y no aparecerá nada interesante en los registros.

Si tengo alguna otra interfaz activa en el host antes de iniciar qemu, entonces la máquina virtual también se inicia, pero el puerto 22 se puede asignar sin problemas. Y ssmostrará:

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

¿Qué está causando este problema? El proceso del host qemu no intenta asociarlo con ninguna de las IP que dependen de las interfaces faltantes.

No estoy usando kvm. aquí está el comando completo:

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;

editar: Más enfoque en systemd

Creo que esto es exclusivamente un problema de systemd. ...suspiro.

iniciar sshd manualmente, usando exactamente el mismo exec que debería haber estado usando systemd, ¡funciona bien! sshd por defecto escucha 0.0.0.0,

Además, todo esto utiliza archivos de distribución estándar. Nada personalizado.

$ 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

(lo comentado fue intentar desbloquear systemd, no hubo suerte)

Además, esto está dentro de una máquina virtual con red de usuario, por lo que siempre tiene una red válida desde el punto de vista de la máquina virtual:

$ 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

y por supuesto, la solución fue que systemd estaba simplemente !(*@&#!@ esperando ntp, ¡para siempre!

tan pronto como me conecte:

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.

¡Lindo! visibilidad cero sobre algo que me impactaría para siempre en caso de que no se pudiera acceder al host ntp o algo así... todavía no estoy seguro de qué está uniendo esas cosas.

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

... ¿Supongo que es porque alguien le adjuntó pacman-init.service? ¿Aunque se omitirá ya que solo se ejecuta para firmar las claves en el primer arranque? Incluso systemctl list-dependencies sshdmostraría todo en verde o omitido. sin advertencias. Qué vergüenza de experiencia.

Respuesta1

El problema era que systemd me estaba engañando. No hacía nada mientras esperaba una dependencia, pero no lo mostraba en ningún registro. Tampoco demostraba que la dependencia que estaba esperando fuera una dependencia de mi servicio.

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

información relacionada