-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Error setting hostname when setting up a centos-7.2 box #7533
Comments
Hi, I have been seeing the same issue with my own Centos 7.2 box (built with Packer). If I use the VMware files created by Packer directly (rather than packaging them into a box and running with Vagrant) then the VM starts fine suggesting that the issue is with Vagrant rather than anything else. Vagrant VersionInstalled Version: 1.8.4 Vagrant pluginsvagrant-aws (0.7.2) VMware FusionProfessional Version 8.1.1 (3771013) Apologies if you are already aware of all this, but... Having taken a closer look into the issue, the root cause (at least at the level of the VM) seems to be that there is a network script configured for the ens33 interface (/etc/sysconfig/network-scripts/ifcfg-ens33) while the actual interface in the Vagrant VM is ens32 (/sys/class/net/ens32). The consequence is that the network.service reports errors due to the 'missing' ens33 interface. When Vagrant does it's stuff to set the host name it restarts the network.service as part of the process - it's at this point that we see the error. I used a bit of a dirty hack using guestfish to rename the /etc/sysconfig/network-scripts/ifcfg-ens33 file to /etc/sysconfig/network-scripts/ifcfg-ens32 and edit the contents accordingly - substituting any reference to ens33 in the file to ens32. I then packaged the altered vmdk file into a Vagrant box and was able to start the VM using 'vagrant up' without error. Hope that helps some with figuring out what is going on (and where) within Vagrant to cause this issue! |
Hello there, I encountered the same issue using box geerlingguy/centos7 (centos 7.2), Details below: Vagrant versionVagrant 1.8.4 Vagrant pluginsvagrant-cachier (1.2.1) Host operating systemDebian 8 Guest operating systemCentos 7.2 VagrantfileVagrant.configure("2") do |config|
config.vm.box = "geerlingguy/centos7"
config.vm.hostname = "server"
end Debug outputvagrant up --debug: Some more logs if i run the command on the guest after vagrant ssh (which works): |
More informations, I tested with older versions of Vagrant: 1.8.3, broken too From @DanHam remark, I also checked if networks were correctly defined, and it seems that a file created by vagrant-libvirt is not correct. It created a network interface eth0, but created a script etc/sysconfig/network-scripts/ifcfg-enp0s3 (and there is no interface enp0s3). Renaming the interface in the script to eth0, repaired, but i really lack some skills here |
The "service network restart" was introduced here: b91c167 but I can't say if something smart can be done to repair broken boxes ( file ifcfg-enp0s3, should'nt be here ... ) |
Hi Vince, So the point I was trying to make (badly!!) above was that something strange was going on to cause a change in the name of the network interface between the time Packer/VMware built the box and Vagrant/VMware ran it. To the best of my knowledge Vagrant doesn't actually do very much at all with regard to setting up the default network interface. Instead it just expects, and in fact requires, the network interface to be correctly configured. In other words the configuration of the interface is done when the box is built, not when it is run with Vagrant. It is the guest itself that determines the name for the network interface - not Vagrant. It used to be the case that network device names were arbitrarily assigned on first boot and then persisted through the use of a udev script. More recently this practice has changed and network interface names are now determined through the use of a tool called biosdevname. Essentially biosdevname uses the location of the network device (as reported by the system BIOS) to set the device name. So, for example, a dual port network card installed in PCI slot 1 on the motherboard will result in the two interfaces named p1p1 and p1p2 respectively - see the link to the Red Hat doc for (better!) details. Clearly, virtual machines don't have physical slots or physical cards and instead everything is emulated. The 'physical' location of devices on the virtual motherboard are then specified within a configuration file. For Virtualbox this is an XML file with the .vbox extension; VMware stores it's settings in a .vmx file. When a Vagrant box is built this file is bundled into the .box file along with the VM's hard disk file and a few others. This file should, and at least for me does include the physical location of the the network interface:
Essentially my box was built with its network card located in PCI slot 33. This results in a network interface of name ens33 and corresponding network configuration script at /etc/sysconfig/network-scripts/ifcfg-ens33. When the box is run with Vagrant the required files for the new VM are copied, imported, and created as required. Unfortunately, the setting specifying what PCI slot the network interface was plugged into is not preserved from the original .vmx file bundled with the box. From my Vagrant machines .vmx file:
This means my Vagrant VM now has a network interface named ens32. The configuration scripts within the VM (/etc/sysconfig/network-scripts/ifcfg-ens33) are not run since the interface clearly doesn't exist. The error we've all seen is the network.service complaining about the fact that this interface is configured - there is an ifcfg-ens33 file - but it is missing from the system. Since the ens32 interface has no corresponding configuration script nothing happens with it and networking for our VM fails! Since I create my own boxes, I have been able to get around this problem (and fix the errors seen) by explicitly setting the location the PCI slot the network card uses in both the Packer build configuration file and the Vagrantfile bundled inside the created box. Explicitly setting this within the user configured or VM specific Vagrantfile should work as well. For VMware the relevant setting can be explicitly defined by setting:
I believe settings for Virtualbox can be configured in a similar way. Of course you do need to know the original setting the box was built with but since Vagrant boxes are essentially just tar archives you should be able to untar the box and take a peek at the .vbox or .vmx file to see what the setting should be! This could be used as a possible workaround until this is fixed... @sethvargo All told, if (!!) I've got all this right then this issue should really be solved by Vagrant reading and using the network card location from the .vbox or .vmx file bundled with the box. This would ensure the network device name is the same as when the box was created and should resolve this issue. Of course, I could have all this wrong and the root cause of the issue may be something else entirely :). However, I can say that what I've done has worked for me... Hope that helps. Dan |
@peetkes The workaround above works OK for me when using the same bento/centos-7.2 box you are using with VMware. Unfortunately I can't figure out how you set the PCI slot to use for the NIC card with Virtualbox... The workaround does not work so well for boxes with multiple virtual NICs - it looks like Vagrant expects the default NIC it uses to communicate with the VM to be in slot 32! With a multi NIC VM it looks as though Vagrant blows away the default ifcfg-ens33 with what should be the second NICs network settings... Fixing the default NIC so it is located in PCI slot 32 in the Packer build configuration file and within the boxes bundled Vagrantfile works well enough and again fixes the issue - even for multi NIC Vagrant machines. Clearly this doesn't help much if you don't have control over the build of the box... |
@sethvargo Hi, I'm afraid this hasn't been fixed by the changes made in the 1.8.5 release of Vagrant. I also think that #7514 is related or caused by the same core issue - although it should be noted that the root cause has nothing to do with setting the host name per se. As stated in previous comments, the error is seen when the network service is restarted. This is because the network service is in a failed state. As such any script restarting the network service will fail (with set -e).
Running journalctl -xe shows us why the network.service is in a failed state:
The ens33 device does not exist. Instead we have ens32.
When the Vagrant box was built the Ethernet device was located in PCI slot 33. This can be seen in the .vmx file bundled with the box. Now we are running the box with Vagrant the Ethernet device is in PCI slot 32. Again this can be seen in the .vmx file under the .vagrant directory or from debug output. Clearly this means that biosdevname will change the name of the network interface. The ifcfg-ens33 network-script intended to configure the network when the box is brought up is never run since the device is now missing. The end result of all this is the failed network.service. Again, I've gotten around this issue with my own CentOS boxes by explicitly setting the PCI slot for the network card to 32 (via vmx settings) both in Packers .json file and in the Vagrantfile bundled with the box. For the bento/centos-7.2 box in question, the issue can be reproduced and worked around with the following Vagrantfile: #-*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
# Box
config.vm.box = 'bento/centos-7.2'
# Configure the guests hostname
config.vm.hostname = 'bento-centos72.localdomain'
# VMware Fusion specific workaround for #7533 and #7514
# Commenting this section out will reproduce the errors
config.vm.provider 'vmware_fusion' do |vf|
vf.vmx['ethernet0.pcislotnumber'] = '33'
end
end Obviously this is a workaround and not a fix... Dan |
Vagrant version
vagrant version 1.8.4
Host operating system
MacOS 10.11.4
Guest operating system
CentOS 7.2
Vagrantfile
Use the following properties file:
Debug output
https://gist.github.com/peetkes/f4896b524c0baaea5b9f9ded43d41854
Expected behavior
Normal startup of a vagrant box
Actual behavior
the box is started but with the error
Steps to reproduce
References
The text was updated successfully, but these errors were encountered: