Add Hyper-V as a supported provider

[lkwdwrd]

As I understand it, VVV works pretty well with VirtualBox, however, it would be very nice to have support for Hyper-V as it comes as part of Windows already and can simply be turned on in most cases. I'm all for using built-in software when possible.

Right now to get VVV working with Hyper-V, you have to make a Customfile to override options and do a bit of hacking around NPM. After deciding to become a dual platform developer and firing up a Windows box, I did some trial and error finding the best SMB mount options to use and got NPM working. In the grand scheme of things, it's relatively little code, so I thought it might be nice to add Hyper-V provider support to VVV itself for ease of other Window's users not wishing to install VirtualBox on their machines.

This PR does just that.

As a side note, I am running @ericmann's forked version of the hosts-updater plugin and things are humming nicely. However it would really great to get #606 in so that a a forked plugin was not necessary. Hyper-V uses a dynamically assigned IP and the standard hosts-updater doesn't support this. The vagrant-ghost plugin does this out of the box.

[jeremyfelt]

Dig it! Thanks for all of that. Is the NPM change necessary for Hyper-V support and is there any chance of it breaking other NPM uses anywhere? I haven't done any research on no-bin-links.

[lkwdwrd]

It's necessary for the SMB shares. NPM install fails in /srv/www/ without
it because SMB doesn't know of or allow symlinks to be created by
default. There is a mount option for CIFS shares (sfu) that renders the NPM
change unnecessary, however, when I had Vagrant mount the folders with the
'sfu' option on, any and all git operations became unbearably slow (wp-cli
took an hour to check out and 30 min to switch branches).

I've played with the --no-bin-links option quite a bit locally and it
doesn't seem to have any effect on the local grunt installs. Ran through
all the WP core grunt tasks and all seemed to fire just fine. That said,
googling around didn't turn up much on potential side effects. Just the
fact it allows NPM to work in SMB shares, and could potentially cause
problems with global modules. It would be nice to know if there were
potentially other ill side-effects of the flag, but so far I have found
none.

On Wednesday, September 9, 2015, Jeremy Felt notifications@github.com
wrote:

Dig it! Thanks for all of that. Is the NPM change necessary for Hyper-V
support and is there any chance of it breaking other NPM uses anywhere? I
haven't done any research on no-bin-links.

—
Reply to this email directly or view it on GitHub
#742 (comment)
.

Luke Woodward – Engineering Manager
10up Inc. http://10up.com | luke.woodward@10up.com | @lkwdwrd

[lkwdwrd]

I may have just found a way around the no-bin-links issue, will do some more testing and report back.

[lkwdwrd]

OK, so I found a set of additional options for the mount.cifs command (what Vagrant uses to mount SMB shares) that didn't show up in any of the Googling I did. Amazing what reading the actual man pages inside the machine does :). Adding the mfsymlinks option makes everything work without needing to run NPM with the --no-bin-links flag and doesn't cause the slow git issues like the sfu option did.

So basically here are the options for the www folder and why I've chosen them to make things work:

• dir_mode=0775: Sets the directory mode to 0775 as with other providers.
• file_mode=0774: Sets the file permission to 0774 as with other providers.
• forceuid: Fixes an issue where composer was unable to work properly with Github. Why? not sure...
• noperm: Fixes issue where untaring files in www tries to reset timestamps on the extracted files and throws errors causing failed provisioning.
• nobrl: Fixes an issue where file locks are used in database operations during provisioning, again causing failures.
• mfsymlinks: Fixes an issue where symlinks are not allowed in www, causing npm install to fail.

Other than these www overrides, the rest of the PR basically switches the box to a Hyper-V compatible one, sets the memory and cpus to be in-line with the other vvv providers, and switches all shared folders to use SMB when using the Hyper-V provider.

It would be great to have others test this, but I've now been able to clone a fresh copy of VVV onto my Surface and run vagrant up without any issues and without installing VirtualBox.

[jeremyfelt]

Sounds good to me. Thanks for doing the extra research!