%20no%20funciona.png)
Al observar la documentación de systemd-nspawn, debe haber sido pensado para tener una forma muy fácil de usar para lanzar contenedores en un espacio de nombres de red diferente. Utiliza la -nopción y simplemente la habilita systemd-networkd.serviceen ambos extremos. El contenedor obtiene su propia dirección IP en uno de los rangos "privados". (DNS puede requerir algunospaso adicional).
El resultado es que obtengo una dirección IP en el rango 169.254.*.*. La ruta predeterminada apunta a la host0interfaz sin pasar por ninguna puerta de enlace/enrutador. Los intentos de llegar a los servidores de Internet, por ejemplo, 8.8.8.8fallan con el mensaje "No hay ruta al host". (No tiene sentido resolver DNS si esto no funciona).
Si ejecuto tcpdump -i ve-fedora-25en el host, puedo ver las solicitudes de DHCP, pero no se responden. systemd-networkd definitivamente se está ejecutando en el host. Los registros del lado del host muestran "Portador obtenido" ve-fedora-25y networkctl lo muestra como "enrutable" y "configurado", todo en verde.
Mi sistema es Fedora 25. Quiero un contenedor de sistema operativo al que pueda conectarme mediante TCP/IP y, al mismo tiempo, poder conectarme con el mundo (por ejemplo, para ejecutar el dnfadministrador de paquetes). Así como libvirtlas máquinas virtuales funcionan tan fácilmente desde el primer momento. ¿Qué ha salido mal?
Respuesta1
El problema es de Fedora.cortafuegos. Parece que nspawn nunca se integró con firewalld. (nspawn tampoco está integrado correctamente con la política SELinux de Fedora).
Como se menciona en la pregunta, libvirt está funcionando bien :). Podemos usar el mismo truco que la gente descubrió para ejecutar contenedores conLXC en Fedora.
Actualización: la solución dejó de funcionar después de actualizar a Fedora 30.
Ejecute systemd-nspawn con la opción --network-bridge virbr0. En lugar de depender systemd-networkd, esto apalanca libvirtd.service. Este último servicio ya está iniciado de forma predeterminada en Fedora. En el invitado, configure su cliente DHCP preferido como de costumbre.
Resolución de DNS al utilizar systemd-networkd como cliente DHCP
Usarlo systemd-networkdcomo cliente DHCP podríaaccidentalmentefuncionará por sí solo, si le queda algo /etc/resolv.confde un arranque de contenedor anterior. Pero no se puede confiar en que esto funcione en general. Realmente está diseñado para ejecutarse junto con systemd-resolved.service.
A su vez, systemd-resolved está pensado para usarse con nss-resolve. Sin embargo, esto no es AIUI esencial.