Vagrant VMware utility uses wrong lease information

[harmjanblok]

If the leases file contains multiple leases (probably due to multiple times vagrant up), the utility cannot determine correct lease.

$ date 
Fri Feb 11 16:04:30 CET 2022

$ cat /var/db/vmware/vmnet-dhcpd-vmnet8.leases | ggrep -A2 -B3 08:00:27:00:00:00
lease 172.16.104.134 {
    starts 5 2022/02/11 14:59:15;
    ends 5 2022/02/11 15:29:15;
    hardware ethernet 08:00:27:00:00:00;
    uid ff:2b:94:34:c1:00:02:00:00:ab:11:57:72:20:7a:3c:a8:92:73;
}
lease 172.16.104.128 {
    starts 5 2022/02/11 14:53:16;
    ends 5 2022/02/11 15:23:16;
    hardware ethernet 08:00:27:00:00:00;
    uid ff:2b:94:34:c1:00:02:00:00:ab:11:76:a3:62:80:96:94:d4:80;
}
lease 172.16.104.135 {
    starts 5 2022/02/11 14:41:19;
    ends 5 2022/02/11 15:11:19;
    hardware ethernet 08:00:27:00:00:00;
    uid ff:2b:94:34:c1:00:02:00:00:ab:11:0c:49:0a:b6:11:16:93:4e;
}
lease 172.16.104.129 {
    starts 5 2022/02/11 14:59:09;
    ends 5 2022/02/11 14:59:09;
    hardware ethernet 08:00:27:00:00:00;
    uid ff:2b:94:34:c1:00:02:00:00:ab:11:a5:59:a6:da:99:b8:37:88;
}
--
lease 172.16.104.136 {
    starts 5 2022/02/11 15:01:37;
    ends 5 2022/02/11 15:31:37;
    hardware ethernet 08:00:27:00:00:00;
    uid ff:2b:94:34:c1:00:02:00:00:ab:11:4b:39:b0:be:45:e4:c2:0d;
}
lease 172.16.104.136 {
    starts 5 2022/02/11 15:01:37;
    ends 5 2022/02/11 15:01:38;
    hardware ethernet 08:00:27:00:00:00;
    uid ff:2b:94:34:c1:00:02:00:00:ab:11:4b:39:b0:be:45:e4:c2:0d;
}
lease 172.16.104.137 {
    starts 5 2022/02/11 15:01:44;
    ends 5 2022/02/11 15:31:44;
    hardware ethernet 08:00:27:00:00:00;
    uid ff:2b:94:34:c1:00:02:00:00:ab:11:98:e9:79:ff:64:87:37:17;
}

The vagrant up --debug shows following output:

DEBUG vmware_driver: Trying to get MAC address for ethernet0
DEBUG vmware_driver:  -- MAC: 08:00:27:00:00:00
 INFO vmware_driver: Reading DHCP lease for '08:00:27:00:00:00' on 'vmnet8'
DEBUG vagrant_utility: request METHOD=GET PATH=/vmnet/vmnet8/dhcplease/08:00:27:00:00:00 RESPONSE=200
DEBUG vmware: Using localhost lookup for SSH info.
DEBUG vagrant_utility: request METHOD=GET PATH=/vmnet/vmnet8/portforward RESPONSE=200
DEBUG vmware_driver: port forwards for IP 172.16.104.134: {:tcp=>{22=>2201}, :udp=>{}}

The machine isn't reachable on 172.16.104.134 (first) but on 172.16.104.137 (last).

Vagrant version

Vagrant 2.2.19

Vagrant VMware plugin version

vagrant-vmware-desktop (3.0.1, global)

Vagrant VMware utility version

1.0.21

Host operating system

macOS Monterey 12.2

Guest operating system

FlatCar Linux

Vagrantfile

# frozen_string_literal: true

Vagrant.configure('2') do |config|
  channel = 'alpha'

  config.ssh.username = 'core'

  config.vm.box = "flatcar-#{channel}"
  config.vm.box_url = "https://#{channel}.release.flatcar-linux.net/amd64-usr/current/flatcar_production_vagrant_vmware_fusion.box"
  config.vm.provider :vmware_desktop do |vmware|
    vmware.gui = true
    vmware.enable_vmrun_ip_lookup = false
  end

  config.vm.define 'master-1' do |master|
    master.vm.hostname = 'master-1'
    master.vm.network :private_network
  end
end

Expected behavior

Expected vagrant up to work as usual.

Actual behavior

Hangs at

Waiting for machine to boot. This may take a few minutes...

[harmjanblok]

Following can be used as workaround:

sudo truncate --size=0 /var/db/vmware/vmnet-dhcpd-vmnet8.leases
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure

[chrisroberts]

Hi there,

Inspecting the box it appears that it is defining a value for the base_mac of the guest. The reuse of the mac is what ends up causing this issue. One option is to disable the value in your local Vagrantfile:

Vagrant.configure("2") do |config|
  ...
  config.vm.base_mac = nil
end

I'm working through some approaches for how to deal with multiple matches (instead of the simple return on first match currently in place).

[eszense]

I ran into the same problem because the official Ubuntu cloud image made two DHCP leases with different client-id (by dhclient and systemd-networkd) with each boot. The config.vm.base_mac = nil workaround hence didn't work.

While a different approach of dealing with multiple matches is needed (maybe to return all IP of matched leases and query each for the current MAC address?), this fix/workaround has solved the issue for me.