This page tracks some known issues or limitations of the VMware provider. Note that none of these are generally blockers to using the provider, but are good to know.
When Vagrant applies port forwarding rules while bring up a guest instance, other running VMware VMs may experience a loss of network connectivity. The cause of this connectivity issue is the restarting of the VMware NAT service to apply new port forwarding rules. Since new rules cannot be applied to the NAT service while it is running, it is required to restart the service, which results in the loss of connectivity.
VMware Workstation has a bug on Windows where forwarded ports do not work properly. Vagrant actually works around this bug and makes them work. However, if you run the virtual network editor on Windows, the forwarded ports will suddenly stop working.
In this case, run
vagrant reload and things will begin working again.
This issue has been reported to VMware, but a fix has not been released yet.
Starting with the Big Sur release VMware Fusion is no longer able to create network devices with custom subnet and mask settings to attach to guests. This means custom IP addresses are not valid when creating a private network. When creating a private network device to attach to a guest, simply define it with no options:
Vagrant.configure("2") do |config| config.vm.box = "hashicorp/bionic64" config.vm.network :private_network end
VMware Fusion currently does not support port forwarding to the localhost. To work around this issue, the vagrant-vmware-utility provides functionality to simulate port forwarding behavior available within VMware Fusion prior to Big Sur. The port forward management is contained to the vagrant-vmware-utility and is not accessible via the VMware Fusion networking UI.
Due VMware Fusion no longer utilizing its own service for DHCP, defining DHCP reservations is currently not working with VMware Fusion on Big Sur.