Support for Parallels Desktop

[TobiasBg]

Parallels Desktop offers an official and open-source Vagrant Provider plugin at http://parallels.github.io/vagrant-parallels/ and https://github.com/Parallels/vagrant-parallels.
The only real differences to our Virtualbox configuration that I have spotted after a quick glance are the box name and the way how machine settings are changed. Both of this can be overridden with provider-specific declarations in the Vagrantfile, as far as I can see.

I'll use this as a tracking issue for my experiments with adding support to VVV.

[TobiasBg]

Looks like this will be pretty smooth. :-)

Here's my setup:

• Parallels Desktop 9 (the latest version is 10) on OS X Yosemite.
• Vagrant 1.6.5.
• Installed the vagrant-hostsupdater plugin (recommend for Virtualbox as well).
• Installed the Parallels Provider plugin via vagrant plugin install vagrant-parallels.

The Vagrantfile needs just a few changes, see https://github.com/TobiasBg/varying-vagrant-vagrants/commit/47c5537d34155e1330b4f49a79302054147d37db:

• Configuration options are changed in a different way. I decided to set 1024MB of RAM, as we do that for Virtualbox as well. Additionally, I told Parallels to keep its Tools in the VM updated and opted for "Better Performance" instead of "Longer Battery Life" (see the docs).
• The Vagrant Box is also hosted in the Vagrant Cloud, but uses a different name, so that we'll have to override the default name (via the "Overriding Configuration" method).
• Finally, when configuring synced folders, we'll have to use different "mount options", as the current ones ("dmode" and "fmode") are specific to Virtualbox. Using the "Overriding Configuration" method, we can set them to the corresponding Parallels options. Details are in this Parallels Provider issue.

That's all that was necessary, so far. VVV is running smoothly in Parallels Desktop with those changes for me.

[jeremyfelt]

Nice! Any way of comparing VirtualBox and Parallels as far as speed / ease goes?

[TobiasBg]

TL;DR: Support for Parallels Desktop works and shows good performance, but needs two more changes.

Ok, here are some more details and findings:

First, I forgot one thing above: To use the Parallels Provider, the very first (and only that) boot of the VM has to be done with vagrant up --provider=parallels. Subsequent boots only need vagrant up.

Further testing revealed that some extra changes to our Vagrantfile and provisioning are necessary, as some errors are raised during provisioning otherwise:

• Un-taring of the three downloaded tar archives (phpMemcachedAdmin, WP Stable, phpMyAdmin) shows a lot of red ("Cannot change ownership to uid 0, gid 0"), but things work.
• npm install in the wordpress-develop site fails (grunt modules in node_modules are empty, except for their package.json, and thus grunt does not work).

The reason for this is file ownership: The Parallels Provider does not support chown (see Parallels/vagrant-parallels#103 (comment)), which tar -x (see fgrehm/vagrant-cachier#53 (comment)) and npm install need/run at one point or the other, if they are invoked as root (which they are, because provision.sh is run as root).
To work around this (in the same way as the approach for wp-cli from #370 (comment)), tar and npm can be run as the vagrant user, as they are run in the user directory and don't require root permissions (see https://github.com/TobiasBg/varying-vagrant-vagrants/commit/2334e2a0685d78818a595d1f03b0788e06983a8c).
(Note: Instead of changing the user for each command separately, we should probably think about running the non-system part of provision.sh as the vagrant user. But that's something for a future ticket.)

Also, we don't need the "share" mount option in the synced folder config for the Parallels Provider (see https://github.com/TobiasBg/varying-vagrant-vagrants/commit/394f0075d8c8267ef935068c8e618c01a72c949f). With that, the file owner is not set to www-data (which is what we want though), but to vagrant.

After those changes, I could not spot any issues or errors and everything looks the same as a Virtualbox VVV (file ownership/permissions (see below) in the VM, locations, ...). :-)
VVV features like auto-site-setup and tools like phpunit, xdebug/Cachegrind/Webgrind, phpMyAdmin, etc. also work flawlessly.

Everything is easy to use and to set up.
If Parallels Desktop is installed, only the above mentioned Parallels Provider plugin has to be installed. After that, the initial vagrant up for each VVV needs to specify the --provider option, with either virtualbox or parallels as the value. In my tests, parallels was the default, if the parameter was not specified. (I'm not sure why that is the case though, as the VAGRANT_DEFAULT_PROVIDER environment variable is empty on my system.) As nothing at all changes if the Parallels Provider is not installed, this is not really an issue or extra step at all.
Nothing changes for existing users or users who only run Virtualbox.

Speed is also better for me. It does feel like sites are loading quicker.
Quick and dirty measured comparisons between Parallels and Virtualbox:

• phpunit (WP Unit Tests in wordpress-develop) runs
  • on average 2.5 min with Parallels and
  • on average 2.9 min with Virtualbox.
• Latency/TTFB in the Chrome Dev Tools when surfing src.wordpress-develop.dev/wp-admin/ (with most pages probably cached):
  • on average 80 ms with Parallels and
  • on average 150ms with Virtualbox.

[TobiasBg]

Ok, it looks like the above

everything looks the same as a Virtualbox VVV (file ownership/permissions in the VM, locations, ...)

is slightly incomplete. File permissions in the shared folder are mainly 644 for files and 700 for newly created directories (like wordpress-develop) or 755 for existing folders (like default). The difference to 775/774 in a Virtualbox VM is the result of :mount_options => [ "dmode=775", "fmode=774" ] not being available in the Parallels Provider.
For Virtualbox, those specific permissions where added in 9b86905, but without stating examples for issues that triggered that change. If anybody can give me suggestions on what to test, that would be great.

[legal90]

@TobiasBg Thanks for implementing Parallels Desktop support here! Let me clarify some points:

In my tests, parallels was the default, if the parameter was not specified. (I'm not sure why that is the case though, as the VAGRANT_DEFAULT_PROVIDER environment variable is empty on my system.)

Since vagrant-parallels v1.3.0 the Parallels provider has higher priority than VirtualBox. If this plugin is installed, Vagrant will try to use the Parallels provider by default. So that, it is not necessary to specify --provider=parallels or set VAGRANT_DEFAULT_PROVIDER env variable anymore.

Also, we don't need the "share" mount option in the synced folder config for the Parallels Provider (see TobiasBg@394f007). With that, the file owner is not set to www-data (which is what we want though), but to vagrant.

No, it is not. "share" mount option means that each user in the guest machine will see these shared folders and files as his own. If you request file uid/gid attributes being logged as 'vagrant' user, than you will see that they are vagrant:vagrant. But if you try to do the same from 'root' account, than you will see root:root and so on. Example:

vagrant@vvv:~$ ls -la /var/lib/mysql/ | grep readme
-rw-r--r--  1 vagrant vagrant      413 Oct 28  2014 readme.txt

vagrant@vvv:~$ sudo ls -la /var/lib/mysql/ | grep readme
-rw-r--r--  1 root root      413 Oct 28  2014 readme.txt

root@vvv:~# sudo -u www-data ls -la /var/lib/mysql/ | grep readme
-rw-r--r--  1 www-data www-data      413 Oct 28  2014 readme.txt

See man mount.prl_fs (in Linux VM) to read more about available mount options for Parallels Shared Folders. This man page is available with Parallels Tools >= 10.1.0 (included to our Vagrant box parallels/ubuntu-14.04 v1.0.1).

[TobiasBg]

@legal90, thanks for those great clarifications!

The higher priority of the plugin explains my confusion there :-) Fortunately, this will not affect VirtualBox-only users of VVV, and users who install the vagrant-parallels plugin probably want that as the default, or can override it easily using the --provider argument or the environment constant.

Your explanation of the "share" mount option also makes sense. For consistency of the file rights with the VVV VirtualBox VM, leaving it out will probably be better, as the file owner will then be www-data while the active user will be vagrant.

[legal90]

@TobiasBg
UPDATE: In Parallels Desktop 10.1.2 it became possible to chown files from shared folders.
Now there is no error like "Operation not permitted" anymore 😃

You can update PD by clicking on the top menu "Parallels Desktop -> Check for Updates...", either download and install the latest build by this link: http://www.parallels.com/directdownload/pd10/

[TobiasBg]

@legal90 Very cool, thanks for the update on this! I'm still on PD 9 and everything is working fine with that now as well (the file access rights are slightly different in the guest VM, compared to the Virtualbox, but I did not run into any issues with that in practice). With this feature in PD 10.1.2, we might be able to strive for even closer matching PD/Virtualbox VMs in the future. But having support for PD 9 is probably also nice :-)

[jeremyfelt]

This is pretty great, @TobiasBg, thanks! And thank you @legal90 for dropping in as well!

I checked out this PR and downloaded Parallels 10 for the first time to try things out. Here was my experience.

On the first vagrant plugin install vagrant-parallels, I got an error with Bundler inside Vagrant.

Net::HTTPNotFound: No gems found matching "vagrant-vmware-fusion" "3.2.0" nil

Strange, but on the next attempt the plugin installed fine. I'm going to blame Vagrant on that one. I'm still on 1.6.5, not sure if 1.7.2 would react differently.

On first vagrant up --provider=parallels, I got an error about a conflicting IP address after the box downloaded for the first time:

==> default: Setting the name of the VM: vvv_default_1420696114870_19801
The specified host network collides with a non-hostonly network!
This will cause your specified IP to be inaccessible. Please change
the IP or name of your host only network so that it no longer matches that of
a bridged or non-hostonly network.

I'm really confused because I destroyed my VirtualBox version of VVV completely. There must be some residual somewhere looking at 192.168.50.4.

I changed the IP in Vagrantfile to 192.168.60.4 and vagrant up then started booting the machine just fine to go through provisioning.

Provisioning went flawlessly. I had forgotten to remove the various WP directories, so it was nice how it was able to svn up in place.

At first I had to correct my hosts entries as they had some old 192.168.50.4 IPs. Once those were gone, then all of the default sites worked great!

For the unscientific speed test:

• Multisite unit tests took 3.09 minutes in Parallels, standard tests took 2.05 minutes.
• Multisite unit tests took 4.59 minutes in VirtualBox, standard tests took 4.35 minutes.

If those times are right, that's pretty fantastic and I might think about ditching VirtualBox for core dev. Wow.

I think my only worry from the entire process is around the IP address. Though my guess is most users will want to use Parallels because they do not have VirtualBox. We're probably ok to see what happens.

As long as we aren't breaking anything on the other end we're probably ok. I ran through a clean vagrant up with VirtualBox to run the unit tests again and things seemed to be fine.

• Any fears with merging this in and starting to officially support Parallels as a provider?
• Does the run as user for tar and npm have any adverse effects for the VirtualBox provisioner?

[TobiasBg]

Very cool, @jeremyfelt! Great testing results!

I'm not sure about that
Net::HTTPNotFound: No gems found matching "vagrant-vmware-fusion" "3.2.0" nil
error, I have never seen that. I assume that it was a temporary network glitch, maybe.

For that IP address conflict: I remember something like this (not sure that it was the same), if I used the Virtualbox VVV, shut that down, and then used Parallels. I always had to reboot my Mac and then start over fresh. I assume that Virtualbox integrates into the OS/network drivers/etc. very tightly and doesn't clean up/unlock everything immediately. That shouldn't be an issue in practice however, except for people who must use both Virtualbox and Parallels for whatever they are doing.

From my side, there are no fears regarding merging this. I've been using this setup for my dev work (a little bit of WP core and plugin development) for the last couple weeks (since opening the PR) without any issues. I'm still on PD 9 and have used Vagrant 1.6.5 mainly, but also successfully updated to 1.7.1 a couple days ago, all with this PR on VVV master.

The file changes should all be safe for Virtualbox users, as they only apply to the Parallels provider, except for that sudo tar/npm thing, which affects everybody. I haven't had any issues with this however, and as we have been doing it with the wp command for a while it should be fine.

[hubdotcom]

In tests, parallels seems to indeed run much faster

Virtualbox 1.7.2
==> default: Provisioning complete in 2218 seconds

wrk -d120 http://local.wordpress.dev/
Running 2m test @ http://local.wordpress.dev/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   199.83ms   60.22ms 544.45ms   91.40%
    Req/Sec    25.40      4.45    34.00     67.08%
  6192 requests in 2.00m, 52.68MB read
Requests/sec:     51.59
Transfer/sec:    449.44KB

vagrant destroy ~ 36 seconds

Parallels 10.2.0
==> default: Provisioning complete in 462 seconds

wrk -d120 http://local.wordpress.dev/
Running 2m test @ http://local.wordpress.dev/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    93.04ms   17.12ms 151.35ms   66.67%
    Req/Sec    54.63      8.62    75.00     65.45%
  13173 requests in 2.00m, 112.07MB read
Requests/sec:    109.76
Transfer/sec:      0.93MB

vagrant destroy ~ 11 seconds