Vagrant issues on Fedora 30

I recently upgraded my dev workstation to fedora 30 and had to go through some hoops to get Vagrant to work. Wanted to bring a couple of things I did to get around.

  1. Fedora 30 Vagrant rpm packages need to be updated to use libcrypt.so.2 · Issue #10830 · hashicorp/vagrant · GitHub <- which is fixed by by this PR Include libxcrypt-compat for compatibility with newer RHEL based hosts by briancain · Pull Request #149 · hashicorp/vagrant-installers · GitHub that got merged upstream. But I dont think there is a vagrant release after this commit.
    So to fix this “dnf install libxcrypt-compat”.

  2. Changes/Vagrant 2.2 with QEMU Session - Fedora Project Wiki . Vagrant up now creates the vms in a user session (so no longer need root/system privileges to provision). However as a side effect “sudo virsh list” will not show the vm that got provisioned while “virsh list” will. Virt-manager will not show the provisioned vms unless you have created a new connection and asked it to look at the user/kvm session.
    vagrant status will ofcourse show the newly provisioned systems, but if you had vm’s prior to upgrade, you will not be able to see/destroy em, because vagrant status only looks at the session space. It also provisions the new vms in a different network, so if you had 2 vms that need to talk to each other you’ll have to work around those.

The Vagrant_2.2_with_QEMU_Session wiki page seems to indicate that we could use libvirt.qemu_use_session = false to get around. It seems to work for vagrant up but there vagrant status and destroy done seem to work :(. Vagrant is unable to look past the session.

If any of you have suggestions on things I could try to get vagrant to look beyond the user session let me know. Thanks

Partha

4 Likes

This PR will configure libvirt to use qemu://system rather than qemu://session by default: https://github.com/theforeman/forklift/pull/981

I also have been having trouble with public_network and macvtap since this change. I switched it back to using qemu:///system and it is now working.

The change in nfs packaging is again screwing up the provisioning if you use nfs as well.