☰

Por que o qemu não consegue iniciar a rede somente do host em loopback quando não há outra rede no host?

tag-icon • tag-icon networking systemd qemu systemd-service
Por que o qemu não consegue iniciar a rede somente do host em loopback quando não há outra rede no host?

Começando qemu-system-x86_64com-nic user,ipv6=off,hostfwd=tcp::9022-:22

Com apenas a lointerface ( 127.0.0.1associada a ela) presente no host, a VM será iniciada, mas qualquer daemon que tentar alocar a porta 22 será interrompido. por exemplo, dentro de vm: #systemctl start sshdirá travar até ser morto e nada de interessante aparecerá nos logs.

Se eu tiver qualquer outra interface instalada no host antes de iniciar o qemu, o vm também será iniciado, mas a porta 22 poderá ser atribuída perfeitamente. E 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))

O que está causando esse problema? O processo host qemu não está tentando associá-lo a nenhum dos IPs que dependem das interfaces ausentes.

Não estou usando o kvm. aqui está o 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: Mais foco no systemd

Eu acho que isso é exclusivamente um problema do systemd. ...suspirar.

iniciar o sshd manualmente, usando exatamente o mesmo exec que o systemd deveria estar usando, funciona perfeitamente! o padrão sshd é escutar 0.0.0.0,

além disso, tudo isso usa arquivos de distribuição padrão. 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

(o material comentado foi tentar desbloquear o systemd, sem sorte)

além disso, isso está dentro de uma VM com rede de usuário, portanto sempre terá uma rede válida do ponto de vista da VM:

$ 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

e claro, a solução foi que o systemd estava apenas !(*@&#!@ esperando por ntp, para sempre!

assim que eu ficar 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.

Legal! visibilidade zero em algo que me impactaria para sempre caso o host NTP não estivesse acessível ou algo assim... ainda não tenho certeza do que está vinculando essas coisas.

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

...acho que é porque alguém anexou pacman-init.service a ele?! mesmo que seja ignorado, pois só é executado para assinar as chaves na primeira inicialização?! até systemctl list-dependencies sshdmostraria tudo verde ou ignorado. sem avisos. Que vergonha de experiência.

Responder1

O problema era que o systemd estava me enganando. Ele não estava fazendo nada porque estava aguardando uma dependência, mas não mostrava isso em nenhum log. Nem mostrava que a dependência que esperava era uma dependência do meu serviço.

Mudou-se parahttps://unix.stackexchange.com/questions/743795/how-to-get-visibility-on-systemd-unit-lifecycle

informação relacionada