Landrush doesn't start with Vagrant 2.2.0 on VMWare Fusion

[nickcharlton]

When bring up a basic Vagrant box using VMWare Fusion, Landrush doesn't appear to start (at all). I am able to start the daemon manually, but when doing that, the IP/hostname isn't configured.

I've confirmed that to bring up the same configuration on VirtualBox (5.2.20) works successfully.

This has worked in the past, so I figure it's a regression somewhere. What do you recommend I look into?

---

Box:

Vagrant.configure("2") do |config|
  config.vm.box = "boxesio/trusty64"

  config.vm.hostname = "example.vagrant.test"
  config.landrush.enabled = true
end

Log output:

$ vagrant up
Bringing machine 'default' up with 'vmware_fusion' provider...
==> default: Cloning VMware VM: 'boxesio/trusty64'. This can take some time...
==> default: Checking if box 'boxesio/trusty64' 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 = "33"
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"] = "33"
WARNING:     end
WARNING:   end
WARNING:
WARNING: For more information: https://www.vagrantup.com/docs/vmware/boxes.html#vmx-whitelisting
==> default: Fixed port collision for 22 => 2222. Now on port 2201.
==> default: Starting the VMware VM...
==> default: Waiting for the VM to receive an address...
==> default: Forwarding ports...
    default: -- 22 => 2201
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2201
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Setting hostname...
==> default: Configuring network adapters within the VM...
==> default: Waiting for HGFS to become available...
==> default: Enabling and configuring shared folders...
    default: -- /Users/nickcharlton/Desktop/landrush-example: /vagrant

$ vagrant landrush status
Daemon status: stopped

---

Vagrant: 2.2.0
VMWare Fusion: 10.1.2
Landrush version: 1.3.0
OS: macOS Mojave (10.14.1)

[hferentschik]

I would expect at some Landrush trace to be in the log, provided of course the configuration hooks for Fusion get triggered -

landrush/lib/landrush/plugin.rb

Line 36 in e10f684

if defined?(HashiCorp::VagrantVMwarefusion)

A couple of things I would try:

• Run in debug mode to see whether additional trace shines some light on this $ VAGRANT_LOG=debug vagrant up
• Un-install the plugin (vagrant plugin uninstall landrush && vagrant plugin install landrush) to see whether this makes a difference
• Try with a different box (just as a sanity check)

[nickcharlton]

Yeah, I was thinking the same. So I ran with DEBUG (you can see the full log output in this gist) and it looks approximately like the following:

[...]
==> default: Machine booted and ready!
 INFO warden: Calling IN action: #<Landrush::Action::InstallPrerequisites:0x000000010226a090>
DEBUG ssh: Checking whether SSH is ready...
[...]
INFO warden: Calling OUT action: #<Landrush::Action::InstallPrerequisites:0x000000010226a090>
[...]
[successfully booted box; end]

• I tried reinstalling when I first came across this.
• I've tried with multiple different box sources (I first saw this on centos/7, which I don't normally use) and since on several I generate myself.

The one thing I haven't done yet is replicating the whole situation on a completely different host machine.

[hferentschik]

So it seems these hooks are working at least. What version of VMWare Fusion are you using and more importantly which Vagrant plugin do you have installed? Do you use the latest vagrant-vmware-desktop plugin?

As far as I understand there have been some changes on how VMware and Vagrant integrate - https://www.hashicorp.com/blog/introducing-the-vagrant-vmware-desktop-plugin. It might be that due to the new plugin further changes are needed to get Landrush working again.

Unfortunately, support for Fusion has always been best effort, since one needs licences for VMWare as well as the Vagrant plugin. For the latter there is not even a trial version available.

Looking at the gist, I am wondering whether the Landrush hooks run too early, but that's atm just a guess.

[nickcharlton]

I looked at this again just now to see if it was still an issue with the collection of moving parts. I can confirm that it's still an issue with:

VMWare Fusion: 10.1.6
Vagrant: 2.2.5
Vagrant VMWare Utility: 1.0.7
Vagrant VMWare Plugin: 2.0.3
Landrush: 1.3.2

Can you suggest somewhere I could go looking to see if I can solve this?

[nickcharlton]

I'm happy to say I've worked out what the problem is here. It is related to the renaming of the Vagrant VMware Plugin, which explains why the hooks just never get called, see:

landrush/lib/landrush/plugin.rb

Lines 35 to 39 in bfef5eb

	# Hooks for VMWarefusion provider
	if defined?(HashiCorp::VagrantVMwarefusion)
	hook.before(HashiCorp::VagrantVMwarefusion::Action::Network, pre_boot_actions)
	hook.after(HashiCorp::VagrantVMwarefusion::Action::WaitForCommunicator, post_boot_actions)
	end

These are now in the HashiCorp::VagrantVMwareDesktop namespace and so defined? always returns false and we never register the two hooks we need.

The solution here is to rename those constants. We'll also need to rename the constant in here too:

landrush/lib/landrush/action/common.rb

Line 8 in bfef5eb

'HashiCorp::VagrantVMwarefusion::Provider' => :vmware_fusion,

1. Should I go ahead and open a PR for this?
2. Can anyone think of another area of the code we should be changing?
3. I notice with the Parallels provider, it warns, should we be doing that, too?

[davividal]

A pull request would be great! :)

I'm not aware of the same issue on Parallels, can you verify please?

[nickcharlton]

Great! I'll get on with that.

I'm not able to test with Parallels, and I'd expect that to be unrelated to this particular issue.

The interesting bit with Parallels is how it writes a warning to the user; any change we make would likely be breaking unless the end-user upgraded all of Vagrant from when it was a Fusion specific provider. What do you think?

[davividal]

Sorry @nickcharlton , I didn't see your comment here before.

The warning you mentioned is this?

landrush/lib/landrush/action/common.rb

Lines 49 to 51 in bfef5eb

	if provider_name == :parallels && Gem::Version.new(VagrantPlugins::Parallels::VERSION) < Gem::Version.new('1.0.3')
	raise "The landrush plugin supports the Parallels provider v1.0.3 and later. Please, update your 'vagrant-parallels' plugin."
	end

[nickcharlton]

Ah yes, that's the one. I think I mentioned this on #358, but it's been long enough I think we can get away with not doing this (I'm happy to make a change if you think otherwise, of course.)

[davividal]

A warning like that would make sense.

[nickcharlton]

I just went to look into adding that warning and hit a snag. Looking at:

landrush/lib/landrush/action/common.rb

Lines 45 to 47 in bfef5eb

	provider_name = SUPPORTED_PROVIDERS.fetch(machine.provider.class.name) do |key|
	raise "The landrush plugin does not support the #{key} provider yet!"
	end

This will now catch the lack of support, but with an error like:

The landrush plugin does not support the HashiCorp::VagrantVMwarefusion::Provider provider yet!

Which wouldn't strictly be true, we do, you just need to upgrade to the one with a new name. I'm thinking here that we could:

1. Split the function of line 45 in two and add the warning in the middle,
2. Leave this as is,

What do you think?

[davividal]

@nickcharlton I honestly don't know.

Leaving it as is will probably result in some user being confused.
On the other hand, splitting the function will increase the complexity without a good reason, IMHO.

My suggestion: leave it as is, but document this somewhere else. Maybe the README?

@hferentschik do you want to weight in on this?

[nickcharlton]

Hah yeah, I had the same problem!

I think it's reasonable to document it, so I'll wait if there's another reply before just doing that on the PR.

[wintermu7e]

I ended in the unfortunate situation where I uninstalled the old vmware plugin trying to fix an issue only to find I can't re-install and have had to use the new desktop plugin. I was using vmware-hostmanager which is similarly afflicted, but there is no activity there. I found landrush this evening but found it wasn't working, and now I know why. I will be very happy if you release a new version soon that works with the new vmware-desktop plugin.

I've been tearing my hair out for days :)

Tony.

[nickcharlton]

I documented the change in the README, in the install section as that seemed a good way to go about it. Let me know if there's a better way to do this!