Skip to content
This repository has been archived by the owner on Jun 25, 2023. It is now read-only.

Landrush doesn't start with Vagrant 2.2.0 on VMWare Fusion #334

Open
nickcharlton opened this issue Nov 13, 2018 · 15 comments · May be fixed by #358
Open

Landrush doesn't start with Vagrant 2.2.0 on VMWare Fusion #334

nickcharlton opened this issue Nov 13, 2018 · 15 comments · May be fixed by #358

Comments

@nickcharlton
Copy link

nickcharlton commented Nov 13, 2018

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
Copy link
Contributor

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

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
Copy link
Author

nickcharlton commented Nov 28, 2018

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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:

# 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:

'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
Copy link
Collaborator

A pull request would be great! :)

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

@nickcharlton
Copy link
Author

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?

nickcharlton added a commit to nickcharlton/landrush that referenced this issue Apr 23, 2020
On 2016-03-26, HashiCorp released the VMware Desktop Plugin, which
replaced the existing VMware Fusion implementation. With the rename, the
hooks that Landrush needs to start services can no longer be called.
Renaming those makes those work again.

Fixes vagrant-landrush#334.
@nickcharlton nickcharlton linked a pull request Apr 23, 2020 that will close this issue
@davividal
Copy link
Collaborator

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

The warning you mentioned is this?

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
Copy link
Author

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
Copy link
Collaborator

A warning like that would make sense.

@nickcharlton
Copy link
Author

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

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
Copy link
Collaborator

@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
Copy link
Author

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
Copy link

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
Copy link
Author

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants