network_name must be specified, and it must be 'default'

[purpleidea]

Hi, I've written a write up of vagrant-libvirt on Fedora 19 [1].

Here is one bug (and workaround) that I found. Fixes upstream would be awesome!
I was asked to report it:

The :libvirt__network_name => "default" needs to always be specified. If you don’t specify it, or if you specify a different name, you’ll get an error:
Call to virDomainCreateWithFlags failed: Network not found: no network with matching name 'default'

[1] https://ttboj.wordpress.com/2013/12/09/vagrant-on-fedora-with-libvirt/

Cheers,
James

[sciurus]

A default libvirt install should set up a network named 'default' for you. I'd need to look over the code in more detail to see how we handle the case where it doesn't exist, or it does already exist but with a different ip range than you've specified.

To improve your experience right now, what I'd recommend is

• destroy and undefine all libvirt networks
• create a network with the following configuration

<network>
  <name>default</name>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0' />
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
    </dhcp>
  </ip>
</network>

• do not use the network name of default in your vagrantfile

then if you do not have any network blocks in your vagrantfile, the VM will be connected to the network named default. If you do specify networks, new ones will be created and your VM will connect to them in addition to the network named default. I explain this a bit more at #89 (comment)

[purpleidea]

With the current setup I have, apart from some other issues, it seems to work fine... To define the network manually would make this less than automatic for new vagrant users, which I'd like to encourage.

Hopefully the information is useful to help you debug the general issue.

[pronix]

is it closed ?

[sciurus]

I believe the issue remains and purpleidea means it "works fine" only if he specifies the network_name.

[purpleidea]

@sciurus Correct, the issue is still present and should not be closed.

Cheers,
James

[sciurus]

James, did this (or your other issues from the blog post) change at all when you moved to Fedora 20? I think I've finished getting a F20 test environment set up, so it's my intention to look at your issues this weekend.

[purpleidea]

@sciurus Awesome!

I did not get a chance to re-test this issue. I would guess that it's still present. At the moment, with my workaround, networking mostly seems to work, however it's a bit awkward. The full Vagrantfile that I use is here:

https://github.com/purpleidea/puppet-gluster/blob/master/vagrant/gluster/Vagrantfile

I wrote about this setup here: https://ttboj.wordpress.com/2014/01/08/automatically-deploying-glusterfs-with-puppet-gluster-vagrant/

This required three separate interfaces, when a maximum of two should be possible. If you succeed in making this work with an improved Vagrantfile, I'd love to hear your changes.

A side note: as mentioned in that above blog post, I couldn't get keepalived working with shorewall enabled. I suspect something funny with libvirt networking, but I couldn't figure it out. I'll need to revisit this at some point with fresh eyes. If you're feeling adventurous, the blog post mentions how to test keepalived with shorewall enabled.

Cheers

[domcleal]

I vaguely remember that it's not libvirt which creates the 'default' network, but virt-manager. Perhaps @purpleidea doesn't use this, so there's no default network present already.

[sciurus]

I believe I have a fix for this in my branch create_default_network. Testing is appreciated.

[purpleidea]

Did not get to test yet. One quick find though:

+        @default_network_name = 'default' if @default_network_name == UNSET_VALUE
+        @default_network_address = '192.168.122.0/24' if @default_network_address == UNSET_VALUE

Since this is the network range and name that libvirt uses by default, my thought would be that we should pick a different set so as to not conflict with whatever the user already has on their machine. Instead I would propose:

+        @default_network_name = 'vagrant' if @default_network_name == UNSET_VALUE
+        @default_network_address = '192.168.121.0/24' if @default_network_address == UNSET_VALUE

[sciurus]

After thinking more about this and dealing with #123 today I agree. I also plan to rename this from default_network to management_network.

[purpleidea]

@sciurus awesome!

[sciurus]

I've deleted the branch I previously mentioned. There's a new branch in the pull request that needs testing.

[sciurus]

Can we close this now?

[purpleidea]

I haven't tested this yet, but feel free to reopen if the patch doesn't address the issue. If I find similar issues when I test I'll open more.

Cheers
James