Vagrant: Make vagrant respect already-configured PCI slots for network interfaces

Created on 8 Dec 2016  ·  3Comments  ·  Source: hashicorp/vagrant

This is a follow-up item to #4590.

In systemd linux, NICs are no longer identified by eth0 or eth1, but instead by an id like ens32 or ens33. The systemd id is based on the NIC's PCI slot. When Vagrant boots a VM it reinitializes the NIC and this can cause the PCI slot to change.

The problem is that the OS has configuration (usually in /etc/network/interfaces) that instructs the OS to initialize a network interface at a particular location (e.g. ens33). When Vagrant changes the PCI slot to 32 the network inside the VM fails to start.

There are two approaches here:

  1. I can guess that Vagrant is going to use PCI slot 32 all the time (this maybe holds true in certain circumstances, but I don't know which ones).

  2. Vagrant can use deterministic behavior to identify the existing NIC specified in the VMX file (which should reflect what is already configured inside the VM).

In any case I just want this to be deterministic so that:

  1. I do not have to add manual overrides to my packer config to support Vagrant, but which render the VM unusable in other contexts
  2. I do not have to add manual overrides in my Vagrantfile.
  3. I do not have to add manual overrides inside the OS to work around Vagrant misbehaving.

Packer -> Vagrant

By default packer initializes the NIC in PCI slot 33, but Vagrant changes this to 32. Instead, I would prefer that Vagrant parse the VMX file and reassign the same PCI slot that is already assigned.

I am also happy to change Packer to always use PCI slot 32 for the NIC _if and only if it can be shown that Vagrant will deterministically use PCI slot 32 when the NIC is reinitialized_. I have not been able to prove this.

I can work around this in at least 3 ways but out of the box this functionality is broken and Vagrant breaks other workflows like VMX builds in Packer, and the workarounds vary by OS so this is rather tedious.

bug providevmware

Most helpful comment

@cbednarski I was able to reliable reproduce the pci slot number change on startup _and_ isolate it to show that the Vagrant plugin is the cause of the slot number modification. I'll get the device setup to not drop custom defined configurations which should clear this up.

All 3 comments

@cbednarski I was able to reliable reproduce the pci slot number change on startup _and_ isolate it to show that the Vagrant plugin is the cause of the slot number modification. I'll get the device setup to not drop custom defined configurations which should clear this up.

Also, this in the Vagrantfile will persist the slot number in current versions:

Vagrant.configure(2) do |config|
   ...
   config.vm.provider :vmware_fusion do |vmware|
     vmware.vmx["ethernet0.pcislotnumber"] = "33"
   end
end

Thanks for looking into this @chrisroberts !

Was this page helpful?
0 / 5 - 0 ratings

Related issues

doomnuggets picture doomnuggets  ·  3Comments

DreadPirateShawn picture DreadPirateShawn  ·  3Comments

barkingfoodog picture barkingfoodog  ·  3Comments

StefanScherer picture StefanScherer  ·  3Comments

jazzfog picture jazzfog  ·  3Comments