Incompatible with Hyper-V Provider (No host IP was given to the Vagrant core NFS helper)

[GuyPaddock]

It probably goes without saying that this plug-in is incompatible with the Hyper-V Provider, but wanted to note it here just in case. Having this plugin installed at all causes Hyper-V guests to fail during vagrant up with the following error:

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

This error is documented in hashicorp/vagrant#7816.

I'm sure that this plug-in tends to be used primarily by VirtualBox users. However, this can be frustrating if you are switching back and forth between the Vagrant and VirtualBox providers because you might not realize that this plugin is what is causing the Hyper-V guests to fail

[ghost]

I would love for this to work with Hyper-V. Now that Docker and Kubernetes are pushing Hyper-V for everything Windows, i am killing myself trying to get a fully functional development workflow back. I cannot seem to get all the pieces working at the same time anymore. The last 2 weeks something is always broken: SSH conflicts with LXSS, SMB Conflicts with "Default Network" on RS3, Docker Machine / MiniKube break docker swarm on older Windows, Loopback doesn't work on LCOW, LCOW breaks HyperV, etc. I can't even remember all the failures I've had recently.

[marcharding]

It should be possible (and quite easy) to fix that, i'll look into it when i find some free time.

[marcharding]

I'll need some help figuring this out, someone with both knowledge of vagrant internals and hyperv networking is needed...

[bbrala]

Hi @marcharding i might be able to help here, I've done quite some work on the hyper-v implementation in vagrant, although is has since been refactored quite a bit.

Leaving this comment here so i can find this issue, not sure when i'll find the time to have a look, but i will at some point.

[bbrala]

Had a first look, and there is a few things that need to implemented for the Hyper V provider. Firstly NFS settings need to be prepared, this includes:

• Find nfs_host_ip and nfs_machine_ip for the provider. (are implemented in the provider)
• Fill nfs_valid_ids with machine id's (maybe we could get away with only this machine's id? Although that is proably not good enough, which means implement a powershell script which lists the VM id')

We could probably hook that up in the enable method, or perhaps there is a cleaner way. I'll look at it again sometime soon.

[bbrala]

I've been looking at the performance of using winnsfd vs using SMB for connecting and it seems like SMB is quite superior in that regard. Hyper-V seems to do some smart things to make SMB very speedy on their virtualized network adapters. My testing seems to indicate there is no performance benefit to using this over just using SMB for connecting.

I use these options for connecting through SMB: type: "smb", mount_options: ["mfsymlinks", "forceuid", "noperm", "file_mode=0777", "dir_mode=0777", "vers=3.0"].

So unless someone can prove me wrong i see no benefit in trying to get this to work on HyperV

[cbj4074]

It appears that the vagrant-winnfsd plugin's mere presence (i.e., the plugin is installed) is sufficient to cause the error:

No valid IDs were given to the NFS synced folder implementation to
prune. This is an internal bug with Vagrant and an issue should be
filed.

In other words, even when the mount type is smb (and not nfs), the error still occurs when the provider is hyperv.

I mention this mostly so people who encounter this problem when switching between VirtualBox and Hyper-V realize that it's necessary to uninstall the plugin completely (and not simply change the shared folder mount type).

[cbj4074]

@bbrala I concur with your assessment regarding there being little to no advantage to using NFS over SMB with Hyper-V.

NFS makes sense with VirtualBox, because, for whatever reason, SMB appears to be 8-10x slower than it is with Hyper-V.

That is to say, Hyper-V with SMB is basically at least as fast as VirtualBox with NFS, in which case, I agree that there is little point in making this plugin compatible with Hyper-V.

Furthermore, SMB has a number of advantages over this specific NFS implementation, particularly with regard to anomalous locking behavior, file name length limitations, unicode character support, etc.

@marcharding It might be simplest just to render the plugin inert when the provider is Hyper-V, which would eliminate the need to keep uninstalling/reinstalling the plugin when switching between providers. Perhaps a warning along the lines of The vagrant-winnfsd plugin does not support Hyper-V because SMB tends to be faster... skipping or similar. It seems like a change of this nature would satisfy the OP's use-case.

[TonyApuzzo]

Fast or slow there is not a single bidirectional shared folder type that works on all desktop hypervisors.

We have people using Host(OSX, Linux, Windows) x (VirtualBox, Hyper-V, vmware) x Guest(Linux, Windows)

The promise of Vagrant allowing a common environment is tantalizing but not realized.

This is the reason to try to get NFS working on Hyper-V IMO (not that I'm competent to do it, sadly.)

Possibly off-topic aside

If Vagrant made it easier to programmatically determine which provider was being used then this weakness would be mitigated.

I guess that HashiCorp prefers that provider/hypervisor abstraction be handled by Packer rather than Vagrant.

[biskyt]

This had me scratching my head for ages today (I had switched from using virtualbox to using hyper-v). This plugin really shouldn't interfere with the boot sequence if hyper-v provider is being used (or if no NFS folders are being mounted).

Uninstalling the plugin solved the problem at least.

[samuel27m]

Thanks @biskyt. Was trying @bbrala solution on Hyper-V and the error kept appearing. Removing the plugin fixed it
vagrant plugin uninstall vagrant-winnfsd