vagrant private_networks & VMware

[vmadev]

Vagrant version

2.1.5

Virtualizer

VMware Workstation 15 Pro

Host operating system

Windows 10 Pro

Guest operating system

Ubuntu 18.04 laravel/homestead v 6.3.0

Vagrantfile

https://github.com/laravel/homestead/blob/master/scripts/homestead.rb

Debug output

No visible bug. Unable to ping ip address as assigned for private_network of 192.168.10.10
x.x.10.10 obviously not pingable however as illustrated in the image below eth0 is pingable.

Expected behavior

Private_network ip address should allow access to server from local host.

Actual behavior

1. VM sets up private ip on eth1
2. VMware automatically assigns IP address to machine on eth0

Steps to reproduce

1. setup laravel/homestead instructions
2. vagrant up using the default yaml config

References

VMware virtual network devices default settings

VM IFCONFIG after provisioning

VMware virtual network devices after machine provisioned

To temporarily FIX

Edit the Virtual network device settings in VMware prior to running vagrant up provisioning and change the NAT subnet address to whatever ip address you intend to use. To keep 192.168.10.10 change the NAT address to 192.168.10.0. When you provision the homestead server you will now be able to reach it using the address as specified in YAML.

[briancain]

Hello @vmadev - I was able to set up a vm using the vmware provider with a private static ip that my host could reach. Do you have a Vagrantfile that reproduces this behavior that isn't laravel/homestead?

[vmadev]

@briancain Are you on VMware 15?

So as you likely already know, Homestead is just ruby scripts that wrap around a vagrantfile so to speak.
Here is the code that sets up the private ip:
'''

Configure A Private Network IP

if settings['ip'] != 'autonetwork'
  config.vm.network :private_network, ip: settings['ip'] ||= '192.168.10.10'
else
  config.vm.network :private_network, ip: '0.0.0.0', auto_network: true
end

'''

I did created a VM directly using an Ubuntu server 18.04 image and it worked as expected. I was able install nginx and reach the public page and ping the server of course.

As you can see on the screen grabs, 2 networks are created in the guest, one that apparently gets assigned an ip address in the subnet of the NAT (this may be the inherent behavior) and another one which is the private ip address in the YAML config file that is loaded into the private_network settings when the vm is provisioned.

Because the NAT already exists in a different subnet, they cant communicate. I cant remember if setting the private IP would automatically take care of the necessary steps to allow them to communicate.

Of course I can just ignore the private ip address on eth1 and use eth0 and its ip address since that one is automatically assigned to work via the NAT but if thats the case then why a private ip settings option?

[chrisroberts]

Hi there. I have spun up a guest with a private network attached using a windows host and the guest is accessible via the private network. Are you still experiencing this issue?

Thanks!

[CartesianDuelist]

I am also getting this issue, and confirm with the above vagrantfile.

[martinandersson]

I have this exact same problem. Stack:

Vagrant 2.2.4
VMware Workstation Pro 15.1.0
Host: Windows 10 Pro
Guest: Both Ubuntu Budgie 18.10 and 19.04

Vagrant file for Ubuntu 18.10:

Vagrant.configure("2") do |config|
  config.vm.box = "pristine/ubuntu-budgie-18-x64"
  config.vm.network "private_network", ip: "192.168.10.10"
end

..or Ubuntu 19.04:

Vagrant.configure("2") do |config|
  config.vm.box = "pristine/ubuntu-budgie-19.04"
  config.vm.network "private_network", ip: "192.168.10.10"
end

I have also tested VirtualBox 6.0.8 which fails even worse. The guest machine won't even boot. The console output has this to say:

Stderr: VBoxManage.exe: error: Failed to open/create the internal network 'HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2' (VERR_INTNET_FLT_IF_NOT_FOUND).
VBoxManage.exe: error: Failed to attach the network LUN (VERR_INTNET_FLT_IF_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component ConsoleWrap, interface IConsole

So I don't think this problem is specific to VMware. We could more generally conclude that Vagrant's application feature to configure networks is, erm.. "limited". Network configuration has for as long as I can remember (and I've been around for some time!) been a real pain in the ass with Vagrant. Here, have some tickets #9134 #9207 #9596 #9726 (last one wrongfully closed).

But especially Vagrant's support for VMware is bottom low. It used to be the case that some VMware problems only happened randomly now and then, but nowadays every single vagrant reload fails with an "addSharedFolder already exists" problem and every first vagrant destroy crashes with a huge stack trace. So some things has obviously worsen over time. I guess that what I am trying to say is that I honestly don't think that anyone should expect networking with Vagrant to become supported any time soon, especially not with VMware, or you'll only get disappointed. At least this is true for Windows host machines. Couldn't say how Vagrant performs on other host systems.

For this particular issue, I tried to configure a private network with all Vagrant releases going all the way back to 2.1.0, using Ubuntu 19.04 and both VM providers. All releases failed. It could be possible that an even earlier Vagrant release work if package ifupdown or net-tools is installed in the box. If anyone finds out, let me be the first one to know! Can't wait to get this problem solved.

I use Vagrant privately to setup networks of VMs for playing around with network based apps like Docker Swarm, Ansible, Hadoop et cetera. For the machines to have network capabilities; be able to communicate with each other and with the host, is quite important. I have spoken with several other Vagrant users who use Vagrant for the exact same thing. At the same time, Windows is the world's most used desktop operating system and Ubuntu is the world's most used Linux distro.

Look, I hate to be the messenger here but I honestly - and with all due respect for the hard challenges Vagrant faces - think that it's about time Hashicorp puts a focus on this issue and sort it out real good once and for all? You should setup a donation page somewhere, I would be the first one to chip in to have this feature provided! =)

[djungowski]

So I was having the same issue and thought this was a regression of #5461. What I found out is, that if you have this line in your Vagrantfile

vmx["ethernet0.pcislotnumber"] = "33"

(which you might need if using older vagrant Versions), then your network interface won't get an IPv4 address if you specify config.vm.network "private_network", ip: "x.x.x.x"

Solution:
Delete the pcislotnumber line. If you can't delete it, because your vagrant Version is too old, you will probably have to update it, so you can delete the line

[martinandersson]

I am using - as of today the latest - Vagrant 2.2.6. The box I've built - using Packer - and which I am using does not set the pcislotnumber, nor does my Vagrantfile in the project. I did notice however that this line you reference is set in the VMX file I find in the VMs home folder.

I tried removing this line, didn't do anything for me. I still can not ping the VM (I set and tried a private network with static IP 192.168.10.10 in this case) nor can the VM ping the host (192.168.10.1). I have tried many many different IP addresses, this doesn't change anything.

I did notice however, that it appears it's not Vagrant that add this "pcislotnumber" line to the VMX file on each boot. If I boot the VM using VMware GUI only (i.e. outside of Vagrant's control), the line still gets reinserted. Furthermore, setting the value to "-1" or "190" (have no idea what those numbers would mean, but I found them on Internet) will still reset the value back to 33.

So bottom line is that I just can't get rid of the weird line of configuration you are referencing. Again, I've never had it outside of the VMs home holder. Not in the box and not in my Vagrantfile. But it does popup in the VMX file of the VM instance on each boot. So having that said, maybe your hack would work if only I could successfully remove it lol

[derhornspieler]

Similar issue but for macOS Sonoma 14.4

Created separate bug report for MacOS here

Error Output using latest Vagrant plugin

sudo vagrant up --provider vmware_fusion
Password:
Bringing machine 'controlplane' up with 'vmware_fusion' provider...
Bringing machine 'node01' up with 'vmware_fusion' provider...
Bringing machine 'node02' up with 'vmware_fusion' provider...
==> controlplane: Verifying vmnet devices are healthy...
Vagrant failed to create a new VMware networking device. The following
error message was generated while attempting to create a new device:

  Networks with custom subnet/mask values are not supported on this platform

Please resolve any problems reported in the error message above and
try again.

Below are the config files. Can't seem to create a private_network with static IPs with paid license file. Very annoying.

# box_name: "sloopstash/ubuntu-22-04"
box_name: "bento/ubuntu-22.04"
# box_version: "2.1.1"
vm:
- name: "controlplane"
  ip: "192.168.201.10"
  memory: "2048"
  cpus: "2"
- name: "node01"
  ip: "192.168.201.11"
  memory: "2048"
  cpus: "2"
- name: "node02"
  ip: "192.168.201.12"
  memory: "2048"
  cpus: "2"

---

require 'yaml'
settings = YAML.load_file(File.join(File.dirname(__FILE__), 'settings.yaml'))

Vagrant.configure("2") do |config|
  config.vm.box = settings['box_name']
  # config.vm.box_version = settings['box_version']
  config.vm.box_check_update = false

  settings['vm'].each do |vm_config|
    config.vm.define vm_config['name'] do |vm|
      vm.vm.hostname = vm_config['name']
      vm.vm.network :private_network, ip: vm_config['ip']
      vm.vm.synced_folder ".", "/vagrant", disabled: false

      vm.vm.provider "vmware_desktop" do |vb|
        vb.gui = false
        vb.memory = vm_config['memory']
        vb.cpus = vm_config['cpus']
      end

      vm.vm.provision "shell", inline: <<-SHELL
        apt update
        apt upgrade -y
        apt install -y wget vim net-tools gcc make tar git unzip sysstat tree
        echo "192.168.201.10 controlplane" >> /etc/hosts
        echo "192.168.201.11 node01" >> /etc/hosts
        echo "192.168.201.12 node02" >> /etc/hosts
      SHELL
      # vm.vm.provision "shell", path: "scripts/common.sh"
    end
  end
end

[mattbaumann1]

I just wanted to ping this again as I am hitting the same issues. @derhornspieler, did you ever figure this out?

[tur11ng]

@mattbaumann1
Me too... Did you figure it out?

[mattbaumann1]

@tur11ng, nope. I haven't spent much time on this. I had a number of other issues to work on that were more pressing so I pushed this to the back burner.