CentOS 7.0 + VMware Provider + Vagrant 1.6.5 = Failure

[skyzyx]

I've already seen #4195 and #4171, and the issue persists.

$ vagrant up
Bringing machine 'dev' up with 'vmware_fusion' provider...
==> dev: Cloning VMware VM: 'dev/centos-7.0'. This can take some time...
==> dev: Verifying vmnet devices are healthy...
==> dev: Preparing network adapters...
==> dev: Starting the VMware VM...
==> dev: Waiting for the VM to finish booting...
==> dev: The machine is booted and ready!
==> dev: Forwarding ports...
dev: -- 80 => 80
dev: -- 443 => 443
dev: -- 22 => 2222
==> dev: Configuring network adapters within the VM...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/ifup eth1

Stdout from the command:

ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth1 does not seem to be present, delaying initialization.

Stderr from the command:

I happen to know that, for whatever reason, the default name of the ethernet interface is eno16777728 instead of eth0.

[Xylakant]

you're bumping into what's called Predictive Network Interface Naming. You can disable that when building the base box, but that's the only a viable workaround I know of.

[johnbhurst]

How do you disable it when building a base box? I'm using Packer and I think I'm hitting this problem.

[Xylakant]

There's multiple options to disable it, you can read about the feature at [1].

I chose the kernel-parameter option which means you need to change two things in your packer builds:

• In the packer config for the build modify the boot_command to include net.ifnames=0 biosdevname=0. Mine now looks like this: "<tab> net.ifnames=0 biosdevname=0 text ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/centos-7.0/ks.cfg<enter><wait>"
• In the kickstart file (ks.kfg) find the line that says --bootloader and append --append="net.ifnames=0". Mine now looks like that bootloader --location=mbr --append="net.ifnames=0"

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html

[hogepodge]

This is a major issue, and needs a better solution. Consistent Network Device Naming is the future, and it would be nice for the VMWare plugin to catch up with the times. It's been in Fedora for quite some time now, and is a real problem for me with regards to my development workflow and CentOS 7.

[mitchellh]

This isn't actually an issue with the VMware provider, but instead with Vagrant core itself. The guest for RHEL/Cent needs to be udpated to detect this and handle it.

[hogepodge]

From this article:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Disabling_Consistent_Network_Device_Naming.html

Using this fix in the image makes networking behave predictably:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

[mattstep]

@mitchellh point me to the part of the vagrant codebase where you think this needs to be fixed, i'll fix it myself, it doesn't seem like anyone else is going to address this.

[mattstep]

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/ifdown ens33

Stdout from the command:

ERROR : [/etc/sysconfig/network-scripts/ifdown-eth] Device ens33 has MAC address 00:0C:29:3E:2D:9C, instead of configured address 00:0C:29:59:C4:97. Ignoring.

[mattstep]

it seems vagrant 1.7.2 appends to the right ifcfg file now for centos7, but it's appending the config 3 times and not removing the default config, it should probably just open the file for write

[phinze]

Hey folks,

Just did a bunch of research into this issue, and I have some updates for you.

Using the latest Vagrant and VMware plugins, the error message as reported by @mattstep is still reproducible on chef/centos-7.0.

I managed to track it down to a file leaked from the bootstrapping process. Even with no additional network interfaces, it shows up at /etc/sysconfig/network-scripts/ifcfg-ens33 with these contents:

# Generated by dracut initrd
DEVICE="ens33"
ONBOOT=yes
NETBOOT=yes
UUID="2c063a06-a598-4d3a-9c70-9f5cc6e1f994"
IPV6INIT=yes
BOOTPROTO=dhcp
HWADDR="00:0c:29:59:c4:97"
TYPE=Ethernet
NAME="ens33"

The hard-coded MAC address in there is the problem - it was generated based on the interface present during bootstrapping, but each new VM is going to boot with its own set of devices with their own hardware addresses.

I've confirmed that removing that file and rebooting the VM causes the MAC address error to go away and everything to behave as expected. It looks like this issue was fixed recently for chef's boxes: chef/bento#321 - it can be fixed in a similar way for other boxes.

So given all this, I'm going to close this as a box-specific issue - feel free to lobby for reopening if you believe there's still a Vagrant-level problem here.

it's appending the config 3 times and not removing the default config,

This is true - it happens in the error case thanks to the fact that there's a >> in a retry block. These blocks get cleaned up on subsequent boots, so it's not a behavioral problem, just a cosmetic one. We should still fix it, but it's a pretty minor thing so I still think the best move is to close this issue.