New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for consistent/persistent network device naming #609

Open
infernix opened this Issue Jun 1, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@infernix
Member

infernix commented Jun 1, 2016

In the latest distros (RHEL7, Ubuntu 16.04, others?) NICs are labelled persistently and not simply eth0-x by order of nic detected.

This poses a problem because we rely on the management interface being a DHCP NIC and if a box image isn't sending out dhcp requests on the right nic, or not starting DHCP at all, we end up nowhere:

DEBUG wait_till_up: Searching for IP for MAC address: 52:54:00:d7:9c:ac
 INFO interface: info: Waiting for domain to get an IP address...
 INFO interface: info: ==> default: Waiting for domain to get an IP address...
==> default: Waiting for domain to get an IP address...
 INFO retryable: Retryable exception raised: #<Fog::Errors::TimeoutError: The specified wait_for timeout (2 seconds) was exceeded>
...

We also may have a situation where the a nic ends up named differently because libvirt attaches it to some different bus or slot (e.g. enp2s0f0 or enp1s0f0 and so on) depending on other devices in the VMs XML. This is a tricky case to handle since we need to know beforehand what the NIC is being called in order to do proper detection/configuration.

This can all be worked around by passing net.ifnames=0 biosdevname=0 on kernel commandline but we should investigate whether if we can fully support persistent naming schemes, provided that box images are configured for that (e.g. by setting DHCP on all possible interfaces) and vagrant supports it (seems OK for RHEL/Fedora but Ubuntu may be lacking support as of Vagrant 1.8.1 in configure_networks.rb)

So if any box image creators/mutators are reading this: use net.ifnames=0 biosdevname=0 in your grub commandlines until this is fixed.

@haggaie

This comment has been minimized.

haggaie commented Jul 19, 2016

I have a scenario where I want to add a PCI passthrough NIC that doesn't have a DHCP server on its link. Would it be possible to have some special persistent name to the interface Vagrant/vagrant-libvirt added and enable DHCP on that interface only?

@infernix

This comment has been minimized.

Member

infernix commented Jul 19, 2016

@haggaie does the virtio management nic not show up as eth0 and the passthrough one as eth1?

@haggaie

This comment has been minimized.

haggaie commented Jul 19, 2016

No, the management nic showed up as eth1 and the passthrough as eth0.

@infernix

This comment has been minimized.

Member

infernix commented Jul 19, 2016

@haggaie try assigning it a different bus and/or slot number, and/or try picking e1000 or rtl8139 for nic_model_type.

@haggaie

This comment has been minimized.

haggaie commented Jul 19, 2016

Is it possible to control the guest bus/slot number via the libvirt.pci method? I don't see it in the template. I'll try another nic model type.

@haggaie

This comment has been minimized.

haggaie commented Jul 19, 2016

Using e1000 as nic_model_type worked. Thanks!

@iam-TJ

This comment has been minimized.

iam-TJ commented Jul 29, 2018

This is becoming even more of an issue now that most distributions are using systemd/udevd > v197 "Predictable Network Interface Names" ( https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ ).

It is definitely something to be solved in this module rather than requiring what could be disruptive changes to the host configuration via kernel command-line net.ifnames=0 biosdevname=0.

I've just started working with vagrant + vagrant-libvirt on Ubuntu 18.04 and lost a day trying to diagnose why a basic ubuntu/bionic64 box fails to start with:

Call to virDomainCreateWithFlags failed: Unable to get index for interface eth0: No such device"

which is directly from libvirt (same error in syslog).

For many hours I thought it was due to my not getting a config.vm.network :public_network, ... statement correct. Finally I commented it out and the error still occurred!

At that point I realised the culprit is the 'hidden' management_network configuration. I dived into the source-code and see that there is no attribute exposed to set the @device value and therefore it uses the default eth0:

lib/vagrant-libvirt/action/create_network_interfaces.rb:85: @device = iface_configuration.fetch(:dev, 'eth0')

This needs documenting as a gotcha up-front for newcomers especially (in docs and in the generated Vagrantfile) and an attribute provided to over-ride the interface device name at a minimum.

It would be preferable to detect the host's interface. Manually that is achieved with:

brctl show $(virsh net-info vagrant-libvirt | awk '/^Bridge:/{print $2}' ) | awk 'NR != 1{print $4}'

I did try working around it using an alias, but that isn't exposed in any useful way as an alternate name, as in:

sudo ip link set virbr1-nic alias eth0

@iam-TJ

This comment has been minimized.

iam-TJ commented Jul 29, 2018

I've just noticed after pulling the source that an attribute has been added as of:

commit 7f50ca2
Author: qazokm qazokm@users.noreply.github.com
Date: Fri Feb 23 12:09:49 2018 +0800

Add basic networking support for qemu session

which has added:

@management_network_device = 'virbr0' if @management_network_device == UNSET_VALUE @system_uri = 'qemu:///system' if @system_uri == UNSET_VALUE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment