Vagrant up stuck on network setup with VMware provider on macOS 11

Vagrant
#1

Hi there,

I am having issues setting up a very basic Vagrant box with VMware provider (Fusion 12) on macOS 11.

This happens when not specifying any network settings at all:

Vagrantfile:

Vagrant.configure(“2”) do |config|
config.vm.box = “centos/7”
end

vagrant up --provider=vmware_desktop
Bringing machine ‘default’ up with ‘vmware_desktop’ provider…
==> default: Cloning VMware VM: ‘centos/7’. This can take some time…
==> default: Checking if box ‘centos/7’ version ‘2004.01’ is up to date…
==> default: Verifying vmnet devices are healthy…
==> default: Preparing network adapters…
WARNING: The VMX file for this box contains a setting that is automatically overwritten by Vagrant
WARNING: when started. Vagrant will stop overwriting this setting in an upcoming release which may
WARNING: prevent proper networking setup. Below is the detected VMX setting:
WARNING:
WARNING: ethernet0.pcislotnumber = “32”
WARNING:
WARNING: If networking fails to properly configure, it may require this VMX setting. It can be manually
WARNING: applied via the Vagrantfile:
WARNING:
WARNING: Vagrant.configure(2) do |config|
WARNING: config.vm.provider :vmware_desktop do |vmware|
WARNING: vmware.vmx[“ethernet0.pcislotnumber”] = “32”
WARNING: end
WARNING: end
WARNING:
WARNING: For more information: https://www.vagrantup.com/docs/vmware/boxes.html#vmx-allowlisting
==> default: Starting the VMware VM…
==> default: Waiting for the VM to receive an address…

Here it’s stuck

This happens when specifying a private network:

Vagrantfile:

Vagrant.configure(“2”) do |config|
config.vm.box = “centos/7”
config.vm.network “private_network”, ip: “192.168.33.20”
end

vagrant up --provider=vmware_desktop
Bringing machine ‘default’ up with ‘vmware_desktop’ provider…
==> default: Cloning VMware VM: ‘centos/7’. This can take some time…
==> default: Checking if box ‘centos/7’ version ‘2004.01’ is up to date…
==> default: 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:
Failed to create new device
Please resolve any problems reported in the error message above and
try again.

Any help is much appreciated!

#2

I confirm, I have exactly the same issue, MacOS Big Sur Beta 10 + Fusion 12 Pro + latest version Vagrant.

#3

I experience the same issue, which is a shame since I discovered this issue just after upgrading VMWare and the vagrant vmware provider (and discovering this upgrade requires a paid upgrade…).
My configuration:
MacOS Catalina + Fusion 12 Pro + latest version of vagrant.

Any chance that we see at least a workaround for this issue?

#4

Hi there,

Fusion on macOS Big Sur behaves much differently than it does on previous versions of macOS. Large parts of Fusion have been re-implemented to utilize the new virtualization and vmnet frameworks provided by macOS. This update was done to remove dependency on kernel extensions due to: “… Apple has been progressively deprecating 3rd party Kernel Extensions or “kexts” which Fusion needs to run VMs…”. You can find more information about this change in this blog post:

We have been testing and debugging Fusion behavior on Big Sur and will be releasing updates for the Vagrant VMware plugin to address the changes once they are ready. It is important to note that Big Sur is still beta and has not been officially released yet, which also means there may be more changes before it becomes generally available.

Fusion also has some limitations when running in Big Sur, the most notable with regards to Vagrant is that port forwarding does not work as it has in the past: https://docs.vmware.com/en/VMware-Fusion/12/rn/VMware-Fusion-12-Release-Notes.html#2636279

Cheers

1 Like
#5

Thank you for this reply, but I don’t understand what I can do to get vagrant working again.

My configuration is :
Mac OS 10.15.7, VMWare Fusion 12, with the last released version of vagrant and the last version of the vagrant-vmware-provider.

My Vagrantfile:
Vagrant.configure(“2”) do |config|
config.vm.box = “generic/centos7”
end

The vagrant up command is stuck here :
$ vagrant up
Bringing machine ‘default’ up with ‘vmware_desktop’ provider…
==> default: Cloning VMware VM: ‘generic/centos7’. This can take some time…
==> default: Checking if box ‘generic/centos7’ version ‘3.0.38’ is up to date…
==> default: Verifying vmnet devices are healthy…
==> default: Preparing network adapters…
==> default: Starting the VMware VM…
==> default: Waiting for the VM to receive an address…

$ vagrant version Installed Version: 2.2.10
Latest Version: 2.2.10

$ vagrant plugin list
vagrant-vmware-desktop (2.1.4, global)

You’re running an up-to-date version of Vagrant!

Any idea for solving this issue, apart from downgrading back to VMWare Fusion 11.

Thanks in advance for your advice.

Kind regards,
Benoît

#6

The behavior on Catalina should not be any different, even with the update to Fusion 12. I’m setting up a local env with Catalina and Fusion 12 to see if i can replicate the behavior you are encountering. Do you experience the same issue when using a different box (like the hashicorp/bionic64 box)?

#7

@chrisroberts Any news on this? Guess the VM has been stuck on “Waiting for the VM to receive an address…” for 7 days?

#8

The latest releases of the Vagant VMware desktop plugin and the Vagrant VMware utility include updates for macOS 11 (Big Sur). However, due to port forwarding functionality not being available within Fusion 12, port forwards will not be functional. This also impacts the Vagrant communicator as it attempts to connect to the guest via the port forward on the loopback. To resolve this, add this to the Vagrantfile:

Vagrant.configure("2") do |config|
  ...
  config.vm.provider :vmware_desktop do |v|
    v.ssh_info_public = true
  end
end

If you want to automatically enable that setting for all vmware guests you bring up on your system, you can add a Vagrantfile with that setting to the VAGRANT_HOME directory (which is ~/.vagrant.d by default).

1 Like
#9

Brings back this error:





I’ve spend hours and hours now to get some VMs running (without luck) and I want my money back at this point.

Big Sur had a beta phase of almost half a year, it’s been known for two years that kexts will stop working. That day is today.

#10

Hello

The issue is from VMware on macos big sur:

I can understand this is not the best experience, so please email us to support@hashicorp.com with your order information, and will process the refund.

Thanks
alvaro

#11

Finally, I managed to get my vagrant setup working again. It needed a full reinstall though.
My guess is that somewhere in my upgrade path, I borked my install.