containers / toolbox

Tool for interactive command line environments on Linux
https://containertoolbx.org/
Apache License 2.0
2.39k stars 208 forks source link

VM with bridged networking cannot be ran properly when using qemu:///session from toolbox. #1402

Open jackorp opened 8 months ago

jackorp commented 8 months ago

Describe the bug A Fedora Silverblue user reported the following bug for vagrant-libvirt: https://bugzilla.redhat.com/show_bug.cgi?id=2248156 After investigating it becomes clearer that the problem is in using qemu:///session to create a VM that uses bridged networking inside toolbox (but less clear what/where should be adjusted to make it work). Using bridged networking by default, qemu-bridge-helper is invoked like this (command picked from error message):

$ /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=27

Which could in theory work IMO.

But the fd is not mapped onto host in any way and remains in container only. Therefore something like the following to try to workaround it does not work:

$ flatpak-spawn --host /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=27
failed to write fd to unix socket: Bad file descriptor

Steps how to reproduce the behaviour

  1. Have Fedora Silverblue (Reproduced on F38 and F39) On host:
  2. rpm-ostree install libvirt
  3. systemctl enable libvirtd virtnetworkd # more services might be needed but I think these should be enough
  4. systemctl reboot # reboot is recommended by libvirt upstream in this case IIRC. 5 toolbox create --release 39
  5. toolbox enter Toolbox:
  6. sudo dnf install vagrant-libvirt
  7. vagrant init fedora/39-cloud-base
  8. vagrant up

Note: it is not vagrant-libvirt specific. Same failure can be achieved by sudo dnf install virt-manager and using qemu:///session connection with VM's networking set to bridged networking configured to virbr0.

Expected behaviour vagrant up succeeds

==> default: Machine booted and ready!

Actual behaviour vagrant up fails with libvirt error

Call to virDomainCreateWithFlags failed: /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=29: failed to communicate with bridge helper: stderr=failed to create tun device: Operation not permitted (Libvirt::Error): Transport endpoint is not connected

Messages were shortened to save from ruby/vagrant specific output.

Screenshots N/A (can provide settings from virt-manager, if desired)

Output of toolbox --version (v0.0.90+) toolbox version 0.0.99.4

Toolbox package info (rpm -q toolbox) toolbox-0.0.99.4-5.fc39.x86_64

Output of podman version

podman version
Client:       Podman Engine
Version:      4.7.2
API Version:  4.7.2
Go Version:   go1.21.1
Built:        Tue Oct 31 15:32:01 2023
OS/Arch:      linux/amd64

Podman package info (rpm -q podman)

$ rpm -q podman
podman-4.7.2-1.fc39.x86_64

Info about your OS Fedora Silverblue 39, from /etc/os-release:

NAME="Fedora Linux"
VERSION="39.20231110.0 (Silverblue)"

Additional context Freshly installed OS, updated before doing anything. Using qemu:///session socket is problematic with bridged networking, Userspace networking instead of bridged networking works. qemu:///system works.

stemid commented 1 week ago

I ran into this issue while googling and my workaround so that I could use tools like vagrant and terraform from a toolbox container is to use qemu+ssh.

Vagrant.configure("2") do |config|
  config.vm.provider :libvirt do |libvirt|
    libvirt.uri = 'qemu+ssh://stemid@localhost/session'
    libvirt.system_uri = 'qemu+ssh://stemid@localhost/system'
    libvirt.storage_pool_path = '/home/stemid/.local/share/libvirt/images'
    libvirt.management_network_device = 'virbr0'
  end
end

This works on a vanilla Atomic Fedora 40 (sway) where libvirt is running on the host, but I also have all the necessary libvirt client libs and packages installed in the toolbox container.