"vagrant provision" fails with "host IP was given to the Vagrant core NFS helper"

[epall]

Following the Quick Start in README.md using vagrant 1.7.4 on OS X 10.10.3, I'm hitting into a snag after my instance comes up during vagrant up:

No host IP was given to the Vagrant core NFS helper. This is
an internal error that should be reported as a bug.

vagrant ssh works fine to get into the box, but no provisioning occurs. If I run vagrant provision explicitly, it errors out the same way:

$ vagrant provision
No host IP was given to the Vagrant core NFS helper. This is
an internal error that should be reported as a bug.

Full log:

$ vagrant up --provider=google
Bringing machine 'default' up with 'google' provider...
==> default: Launching an instance with the following settings...
==> default:  -- Name:            i-2015071919-2a06374a
==> default:  -- Type:            n1-standard-1
==> default:  -- Disk type:       pd-standard
==> default:  -- Disk size:       10 GB
==> default:  -- Disk name:
==> default:  -- Image:           debian-7-wheezy-v20140619
==> default:  -- Zone:            us-central1-b
==> default:  -- Network:         default
==> default:  -- Metadata:        '{}'
==> default:  -- Tags:            '[]'
==> default:  -- IP Forward:
==> default:  -- External IP:
==> default:  -- Preemptible:     false
==> default:  -- Auto Restart:    true
==> default:  -- On Maintenance:  MIGRATE
==> default:  -- Autodelete Disk: true
==> default:  -- Scopes:
==> default: Waiting for instance to become "ready"...
==> default: Machine is booted and ready for use!
==> default: Waiting for SSH to become available...
==> default: Machine is ready for SSH access!
No host IP was given to the Vagrant core NFS helper. This is
an internal error that should be reported as a bug.

Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.vm.box = "gce"

  config.vm.provider :google do |google, override|
    google.google_project_id = '<CENSORED>'
    google.google_client_email = '<CENSORED>'
    google.google_json_key_location = '<CENSORED>'
    override.ssh.username = 'epall'
    override.ssh.private_key_path = '~/.ssh/id_rsa'
  end
end

[Temikus]

TO/ @epall

Hi Eric,

Thanks for reporting this!

TL;DR: This is a regression introduced by https://github.com/mitchellh/vagrant-google/commit/621d95491ef922efe949bbbdeae11092ee14b11d, can be worked around by using:

override.nfs.functional = false

However, I cannot currently reproduce this using your Vagrantfile on the following environment, so can you at least give me a debug log vagrant --debug up?

I'm trying to reproduce on the following setup: OSX 10.10.4 Vagrant 1.7.4 vagrant-google 0.2.0 Virtually identical Vagrantfile:

Vagrant.configure(2) do |config|
  config.vm.box = "gce"

  config.vm.provider :google do |google, override|
    google.google_project_id = ''
    google.google_client_email = ''
    google.google_json_key_location = ''
    override.ssh.username = 'temikus'
    override.ssh.private_key_path = '~/.ssh/id_rsa'
  end
end

Everything's working as it should:

λ vagrant up                                                        (1)
Bringing machine 'default' up with 'google' provider...
==> default: Launching an instance with the following settings...
==> default:  -- Name:            i-2015072011-31e57741
==> default:  -- Type:            n1-standard-1
==> default:  -- Disk type:       pd-standard
==> default:  -- Disk size:       10 GB
==> default:  -- Disk name:
==> default:  -- Image:           debian-7-wheezy-v20140619
==> default:  -- Zone:            us-central1-b
==> default:  -- Network:         default
==> default:  -- Metadata:        '{}'
==> default:  -- Tags:            '[]'
==> default:  -- IP Forward:
==> default:  -- External IP:
==> default:  -- Preemptible:     false
==> default:  -- Auto Restart:    true
==> default:  -- On Maintenance:  MIGRATE
==> default:  -- Autodelete Disk: true
==> default:  -- Scopes:
==> default: Waiting for instance to become "ready"...
==> default: Machine is booted and ready for use!
==> default: Waiting for SSH to become available...
==> default: Machine is ready for SSH access!
==> default: Rsyncing folder: /Users/temikus/Code/vagrant-dev/lab-vagrant-prerelease/ => /vagrant
2.1.6 ~/Code/vagrant-dev/lab-vagrant-prerelease [11:28:28]∞
temikus λ vagrant ssh
temikus@i-2015072011-31e57741:~$ exit
logout
Shared connection to 130.211.181.121 closed.
2.1.6 ~/Code/vagrant-dev/lab-vagrant-prerelease [11:28:51]∞
temikus λ vagrant provision
==> default: Rsyncing folder: /Users/temikus/Code/vagrant-dev/lab-vagrant-prerelease/ => /vagrant

Are there any differences from this in your config? Since you did mention that the machine fails during provisioning, I presume you do have a provisioner specified. Can you share the provisioner config or at least the type?

Thanks!

Cheers, A.

[epall]

Hmm. Works fine for me on my work laptop, so I'll have to get back to you in a few days when I get some time to debug on my home laptop.

I haven't configured any provisioner, but I'm expecting it to rsync /vagrant with the default configuration, or at least exit with status 0.

I use gpg-agent as my SSH agent, and it's been acting up since I upgraded to Yosemite. Could that be connected to this issue?

[Temikus]

@epall

I'm not sure why this is happening on certain machines and not happening on others exactly, but I found the reason why this happens. The new SyncedFolders action detects that nfs is available on the machine, but nfs_machine_ip and nfs_host_ip env variables required for it are not set.

This is a problem for all remote-instance based providers using this action: vagrant-vcenter: https://github.com/gosddc/vagrant-vcenter/issues/5 vagrant-rackspace: https://github.com/mitchellh/vagrant-rackspace/issues/113 vagrant-aws: https://github.com/mitchellh/vagrant-aws/issues/357https://github.com/mitchellh/vagrant-aws

There was an upstream bug about it, where mitchell recommended to export those variables correctly: https://github.com/mitchellh/vagrant/issues/4192

However, the problem is that even with variables exported, this will fail, since default firewall rules will not allow it. I can hack around and set each synced folder type to rsync, but this seems like a very inelegant solution. I'll try to figure this out this week. If not - I will roll back to old behaviour while I get an idea of how to carefully implement it.

[epall]

Ah, that makes sense. Would it be possible to actually support NFS shared folders by using a reverse SSH tunnel (ssh -R 12049:localhost:2049 ...) and forcing NFS to use TCP?

[Temikus]

@epall AFAIK Vagrant uses NFSv3 by default and v3 doesn't have predictable port forwarding. NFSv4 is configurable, but not all guests will support it, so it'll be tricky. Not mentioning the NFS-over-wide-Internet weirdness.

But I'm open to suggestions. What do you think? Would there be any benefit in NFS support for your use-cases?

[epall]

Ough. I guess there's still the possibility of tunneling, but now you're talking about superuser access to screw around with network interfaces both locally and remotely. Seems brittle and error-prone, though maybe not that much worse than NFS in the first place.

The rsync-powered synced folders is plenty for my immediate use-case, because I'm just using vagrant to test out a puppet config before pushing it to a production box.

For other use cases, being able to edit files locally and run them remotely on a vagrant box in GCE (without a 20+-second vagrant provision) would give me a best-in-class development experience leveraging powerful remote resources. I'm specifically targeting cross-compilation of OpenWRT, which is a CPU-, RAM-, and disk-intense process that my little Macbook Pro bogs down on.

[Temikus]

@epall Ah, for syncing files remotely without provisioning, there are now vagrant rsync and vagrant rsync-auto commands, second will actually poll fs events and fire off syncing when files are changed. Support for these is one of the reasons I implemented SyncedFolders action that caused this in the first place :-P

[epall]

oh, snap! That's fantastic.

[Temikus]

This has been temporarily reverted by #96 and 0.2.1 has been pushed to public. A possible fix is ready (rewrites folder configs on up to set type to rsync), but needs more testing to make sure it doesn't break multi-provisioner and multi-provider setups. ETA - 2-3 weeks.

[Temikus]

Submitted a bug upstream, will see what vagrant folks reply.

[Temikus]

@epall This should be fixed, new release that uses built-in rsync is now available.

[Temikus]

I'm closing this issue since this looks resolved. However, if you still have any questions - no worries at all - just reopen and I'll help you right out!