Skip to content
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

1.8.6: Vagrant private network is incorrectly configured due to sorting of interface names if Docker is installed #7844

Closed
BlueMonday opened this issue Sep 29, 2016 · 6 comments · Fixed by #7848

Comments

@BlueMonday
Copy link

BlueMonday commented Sep 29, 2016

Vagrant version

1.8.6

Host operating system

ArchLinux

Guest operating system

CentOS 7

Debug output

DEBUG network_interfaces: Unsorted list: ["enp0s3", "enp0s8", "docker0"]
DEBUG network_interfaces: Sorted list: ["docker0", "enp0s3", "enp0s8"]
DEBUG ssh: Uploading: /var/folders/7b/7mhr441d32q9t25f7r_c30h00000gp/T/vagrant-redhat-configure-networks20160928-13678-1s0qhn4 to /tmp/vagrant-network-entry-enp0s3-1475102022-0
DEBUG ssh: Re-using SSH connection.
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: # Down the interface before munging the config file. This might
# fail if the interface is not actually set up yet so ignore
# errors.
/sbin/ifdown 'enp0s3' || true

# Move new config into place
mv '/tmp/vagrant-network-entry-enp0s3-1475102022-0' '/etc/sysconfig/network-scripts/ifcfg-enp0s3'

# Bring the interface up
ARPCHECK=no /sbin/ifup 'enp0s3'
 (sudo=true)
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false)
DEBUG ssh: Exit status: 0
 INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-s1ZuUuAtJS/agent.6490
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...

Expected behavior

Vagrant should determine the adapter to network interface mapping correctly when Docker is installed and configure the correct interface as part of the private network.

Actual behavior

The change in #7705 can cause Vagrant to incorrectly map adapters to interfaces if a private network is configured by Vagrant and Docker is installed on the Vagrant box. This results in vagrant up hanging indefinitely.

I believe this is what is happening (I might have diagnosed the root cause incorrectly and I may have butchered some of the terminology... sorry):

  • With the Virtualbox provider plugin, Vagrant creates a dictionary of network adapters which includes a NAT adapter by default (see https://github.com/mitchellh/vagrant/blob/master/plugins/providers/virtualbox/config.rb#L80).
  • Much later the Virtualbox provider plugin maps the adapters to the interfaces based on their indexes (see https://github.com/mitchellh/vagrant/blob/master/plugins/providers/virtualbox/config.rb#L80). For example, the 2nd adapter gets mapped to 2nd interface.
  • Previously the order of the interfaces was based on the order they appeared in the ip addr command. The interfaces are now ordered alphabetically.
  • The first interface is always mapped to the NAT adapter
  • If the VM has an interface with a name that is alphabetically ordered before the actual interface that corresponds to the NAT adapter Vagrant incorrectly maps that interface to the NAT adapter.
  • The interface corresponding to the private network is then mapped to the interface corresponding to the NAT adapter and everything goes down hill from there.

For example:

Previously the list of network interfaces would be something like:
["enp0s3", "enp0s8", "docker0"]

The first interface (enp0s3) was mapped to the NAT adapter and the second interface (enp0s8) was mapped to the adapter connected to the private network.

The list of network interfaces is now sorted so the list is now:
["docker0", "enp0s3", "enp0s8"]

The docker0 interface is now mapped to the NAT adapter and enp0s3 is now mapped to the adapter connected to the private network. When Vagrant overrides the configuration for the enp0s3 interface with the configuration meant for enp0s8, the VM is unable to reach the outside.

docker0 is created and configured by Docker by default. I think I might be able to work around the problem by configuring docker to create the interface with a different name. I think running Docker inside a Vagrant box might be a common use case though?

Steps to reproduce

  1. Download a Vagrant box with Docker installed
  2. Configure the Vagrantfile to create a private network
  3. vagrant up hangs indefinitely

References

@BlueMonday
Copy link
Author

@chrisroberts

@derks
Copy link
Contributor

derks commented Sep 29, 2016

Just upgraded to Vagrant 1.8.6 and VirtualBox 5.1.6, and am experiencing this same issue with VMs that have Docker running. In my use case, I have the following interfaces:

  • docker0
  • eth0 (NAT)
  • eth1 (Host Only)
  • eth2 (Host Only)

In my Vagrantfile I have something like the following:

config.vm.network(:private_network, {
  ip: "172.100.1.10",
  auto_config: true,
  name: "vboxnet1",
})

config.vm.network(:private_network, {
  ip: "172.100.2.10",
  auto_config: true,
  name: "vboxnet2",
})

What I end up with is that docker0 is untouched, and eth0 is the right NAT address (10.), however eth1 has the ip that eth2 is suppose to have, and eth2 is not configured at all.

@BlueMonday
Copy link
Author

Thanks for fixing this so quickly @chrisroberts, really appreciate it!

@jhhinrichsen
Copy link

It would be very helpful if you could either:
-- put out a release with just this fix, or
-- provide a workaround that correctly renames the docker0 network interface so that it does not precede eth0 in the sort order

mikefaille added a commit to mikefaille/nixpkgs that referenced this issue Nov 14, 2016
I upgrade vagrant mainly for this bug :
hashicorp/vagrant#7844
harryxu added a commit to harryxu/dserver that referenced this issue Jul 27, 2017
@suibinz
Copy link

suibinz commented Dec 18, 2017

I think this issue still exists on: Vagrant 1.9.1 with VirtualBox 5.1.30r118389.

my Centos7 has (eth0, eth1, eth2) that are mapped to Virtualbox (Adaptor2, Adaptor3, Adaptor1)

@ghost
Copy link

ghost commented Mar 31, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants