Vagrant up fails on unknown network 'default' - vagrant-libvirt

Ask Fedora
1

I’m trying to use vagrant to spin up a test environment that I would later automate with ansible. For this purpose, I prefer to have stable IPs across different runs of vagrant.

I noticed that vagrant would work if no custom ip is specified, but if I do it fails for not being able to find the network: ‘default’. Also creating the network with unprivileged virsh results in an Operation not allowed error: `error: error creating bridge interface virbrX: Operation not permitted`

I’m running Fedora 41.

I’m using an unprivileged user for this setup:

uid=1000(myusr) gid=1000(myusr) groups=1000(myusr),10(wheel),36(kvm),983(libvirt),1001(plugdev)

The /etc/libvirt/libvirtd.conf file is at its default.

Follows a Vagrantfile that fails on my machine:

Vagrant.configure("2") do |config|
  config.vm.define "box" do |box|
    box.vm.box = "fedora/41-cloud-base"
    box.vm.network "private_network", ip: "192.168.124.123"
  end 
end

The error:

/usr/share/gems/gems/fog-libvirt-0.9.0/lib/fog/libvirt/requests/compute/vm_action.rb:7:in `create': Call to virDomainCreateWithFlags failed: Network not found: no network with matching name 
'default' (Libvirt::Error)

What is the status of vagrant on Fedora? I saw a couple of bugzillas about the change of license and that version 2.4.0 and subsequent will not be taken into consideration by fedora. Should I consider an alternative to Vagrant?

2 
sudo dnf install libvirt-daemon-config-network
sudo systemctl enable virtnetworkd.service
sudo systemctl restart virtnetworkd.service
virsh -c qemu:///system net-start default
3

If I do that it says:
error: Failed to start network default
error: Requested operation is not valid: network is already active

Same goes for other networks that I would like to create as the user, that already exist in the root “context”, if there even is such thing as “context” here.

This is what I’m seeing as normal user:

$ virsh net-list

 Name   State   Autostart   Persistent
----------------------------------------


$ virsh net-list  --all

 Name     State      Autostart   Persistent
---------------------------------------------
 jacket   inactive   yes         yes

This is what I’m seeing as root user:

$ sudo virsh net-list

Name          State    Autostart   Persistent

default       active   yes         yes
jacket        active   yes         yes

I’m starting to think if user’s jacket and root’s jacket are the same thing…

5

Run as a normal unprivileged user:

virsh net-define /dev/stdin << EOF
<network>
<name>default</name>
<forward mode="bridge"/>
<bridge name="virbr0"/>
</network>
EOF
virsh net-autostart default
virsh net-start default

Also change the IP in the Vagrantfile to match this subnet:

virsh -c qemu:///system net-dumpxml default --xpath //ip
1 Like
6

It works :tada:
But I’m curious about what is happening in the background.
This new default network uses the same virtual bridge and ip addresses of the root default network. Are they distinct entitites?

7

Apparently Vagrant expects the VM and default network to run in the same mode, but libvirt requires virtual networks to run in privileged mode, and we cannot address it by name from unprivileged mode, so we define an unprivileged virtual network as a bridge using the same interface, which makes it a separate entity only in terms of libvirt.

2 Likes
8

I said it works too fast. Better.. it works in the sense that vagrant does not complain anymore about the default network, but then it ignores the ip directives in the vagrantfile:

vagrantfile

Vagrant.configure("2") do |config|
  config.vm.define "box" do |box|
    box.vm.box = "fedora/41-cloud-base"
    box.vm.network "private_network", ip: "192.168.124.123"  <==== Desired IP
  end
end

Actual ip

vagrant ssh-config
Host box
  HostName 192.168.124.254   <===== Actual ip
  User vagrant
  Port 22
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /home/x/projects/dirty/.vagrant/machines/box/libvirt/private_key
  IdentitiesOnly yes
  LogLevel FATAL
9

There’s some info about the state of support for unprivileged mode in Vagrant:
Support user session libvirtd (qemu:///session) · Issue #272 · vagrant-libvirt/vagrant-libvirt

They claim it requires a newer version of the libvirt backend to work correctly.

Unfortunately, Fedora provides an older version that may not fully support unprivileged mode, specifically the part related to network configuration:
2188844 – vagrant-libvirt-0.12.2 is available

Personally, I prefer using hostnames over IPs:

sudo dnf install libvirt-nss
sudo authselect enable-feature with-libvirt
1 Like
10

Nice, I didn’t know about libvirt-nss. Tough luck for the IPs.

In the end I decided to move forward with vagrant’s ssh-config output. It works for my use case. The drawback is that if you redeploy, you’ll need to update the resulting ssh config file as well.

vagrant ssh-config > ~/.ssh/config.d/vagrant-project_123