Если посмотреть на документацию для systemd-nspawn
, то, должно быть, она была предназначена для очень удобного для пользователя способа запуска контейнеров в другом сетевом пространстве имен. Вы используете опцию -n
и просто включаете ее systemd-networkd.service
на обоих концах. Контейнер получает свой собственный IP-адрес в одном из «частных» диапазонов. (DNS может потребовать некоторыхдополнительный шаг).
В результате я получаю IP-адрес в диапазоне 169.254.*.*
. Маршрут по умолчанию указывает на host0
интерфейс без прохождения через какой-либо шлюз/маршрутизатор. Попытки связаться с интернет-серверами, например, 8.8.8.8
терпят неудачу с сообщением "Нет маршрута к хосту". (Нет смысла работать с DNS, если это не работает).
Если я запускаю tcpdump -i ve-fedora-25
на хосте, я вижу запросы DHCP, но на них нет ответа. systemd-networkd определенно запущен на хосте. Журналы на стороне хоста показывают "Gained carrier" на ve-fedora-25
, а networkctl показывает это как "routable" и "configured" все зеленым цветом.
Моя система — Fedora 25. Мне нужен контейнер ОС, к которому я могу подключиться с помощью TCP/IP, и в то же время иметь возможность подключаться к миру (например, для запуска dnf
менеджера пакетов). Так же, как libvirt
виртуальные машины работают так легко из коробки. Что пошло не так?
решение1
Проблема в Fedorafirewalld. Похоже, nspawn никогда не был интегрирован с firewalld. (nspawn также некорректно интегрирован с политикой SELinux Fedora).
Как упоминалось в вопросе, libvirt работает отлично :). Мы можем использовать тот же трюк, который люди обнаружили для запуска контейнеров сLXC на Fedora.
Обновление: обходной путь перестал работать после обновления до Fedora 30.
Запустите systemd-nspawn с опцией --network-bridge virbr0
. Вместо того, чтобы полагаться на systemd-networkd
, это использует libvirtd.service
. Последняя служба уже запущена по умолчанию в Fedora. В гостевой системе настройте предпочитаемый DHCP-клиент как обычно.
Разрешение DNS при использовании systemd-networkd в качестве DHCP-клиента
Использование systemd-networkd
в качестве DHCP-клиента можетслучайноработать самостоятельно, если у вас есть остатки /etc/resolv.conf
от предыдущей загрузки контейнера. Но вы не можете полагаться на то, что это будет работать в целом. Он действительно разработан для работы вместе с systemd-resolved.service
.
В свою очередь systemd-resolved предназначен для использования с nss-resolve
. Однако это не обязательно AIUI.