vagrant up fails on centos 7 at 'configuring and enabling network interfeaces' with guest additions installed

[Daemoen]

Vagrant version

vagrant --version
Vagrant 1.8.1

Host operating system

system_profiler SPSoftwareDataType
Software:

    System Software Overview:

      System Version: OS X 10.11.5 (15F34)
      Kernel Version: Darwin 15.5.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: mmercer-utmbp
      User Name: Marc Mercer (mmercer)
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 4 days 14:05

Guest operating system

CentOS Linux 7 (Core)
Kernel 3.10.0-327-18.x.el7x86_64 on an x86_64

Vagrantfile

https://gist.github.com/Daemoen/6ec91971bd73eb772836e739bcaeac89

Debug output

Warning: This file is long 40K lines plus. Relevant lines do not start until near the bottom, so just skip to the end and work backward.

https://gist.githubusercontent.com/Daemoen/325ace92421e28250cf3a68792010050/raw/11420a3a295b478d49b34d01e74d32bb5ca98d12/vagrant%2520up%2520--debug

Expected behavior

• vagrant up should complete
• vagrant should attach network interfaces
• instance should be accessible.

Actual behavior

• vagrant up stalls
• ssh keepalives begin being sent

Additional Note: Strangely, even after ctrl^c is sent to the vagrant command, the keepalives continue, and we are forced to repeat the interrupt.

Steps to reproduce

1. vagrant up utbase-c7
2. wait

References

Have not seen anything particularly matching, the closest match may be: #6207

The difference is that in my case, I am bringing the instance up, not halting it. Though the interrupt should begin the halt phase, and also encounters it.

[sethvargo]

Hi @Daemoen

Thank you for opening an issue. Unfortunately neither that box file nor those ansible files are accessible for us to reproduce this issue. Are you able to produce this issue with a vanilla vagrantfile (no provisioners) and a public box from Atlas?

[Daemoen]

@sethvargo amusingly, there are no provisioners being used on that machine ;) note that

'book' => ''

in the config. If no book is defined, then ansible does not actually get executed. The box is actually built via packer, and goes through the process of provisioning for packer. I use it as a baseline image configured for work with the normal vagrant+virtualbox requirements (including dkms and guest additions), and of course our 'common' packages.

I will test it against the Atlas box when I get back to the house in a bit.

[Daemoen]

@sethvargo Please see: https://github.com/Daemoen/vagrant_debug

Everything has been verified and tested numerous times. It does assume you are building the box with packer, even doing it manually, it is still reproducible.

I opted not to place the iso and such in it myself as I feel that defeats the purpose of validation. (I removed them each time just to make sure it was valid).

[Daemoen]

Ok, so the bug has to be somewhere in the provisioning/boxing phase, as the bento C7 box works with the vagrantfile above.

Will test this a bit more and report back any findings.

[Daemoen]

Ok, so I have gone through and compared all of the chef bento steps to my own, and the only major difference I see is that they do not do updates (well, and they also deal with network interface persistence; ill add that shortly).

I did notice that on my initial boot, when the kernel comes up, it has not yet loaded the vbox modules, so I will need to determine what is causing the race condition and preventing them from finishing.

I'm going to do some more testing, and maybe we can ensure that certain steps are followed (documentation) if a user does updates and such, so that they know that the updates and dkms have always occurred correctly. Will post more info later (today/tomorrow).

[sethvargo]

Hi @Daemoen

It's likely that the version of the vbox modules (or the kernel itself) is out of date. Sadly there's no much Vagrant can do here. We do print a message when your vbox guest additions are out of date, but that's pretty much the extent we can go 😦

[Daemoen]

Ok... so I finally found what I believe to be the root cause of this.

In my boxing step, I am specifically setting the interface type of the original adapter to virtio, which causes this interface to register as eth0. Later on, when the box is spun up with my Vagrantfile, I have a second adapter added, but I do not specifically set the adapter type, so it uses the default (all well and good).

Herein is where it gets amusing:
Because the first adapter is using the virtio type and assigned eth0, when the second adapter is attached, it uses the newer format of naming (pci riser/slot/etc), so we wind up with for instance: enp0s8...

As best as I can tell, when both types are present, the configuring phase gets totally confused and is unable to proceed because it finds eth0, so it goes to use the eth* format name, but there is more than eth_, there is eth0 and enp_.

It might take some time to fully investigate this, but for now, I have found the resolution. Just sharing info for knowledge sake.

[sethvargo]

This will be fixed in 1.8.3 because all guests use predictable network name detection now 😄