VirtualBox performance in windows

We’ve recently moved to using Bedrock-ansible and Sage, and love the setup. Took a while to get things going on Windows but now it is running, I’m happy, although yet to push a project live. Having one major problem though, the speed of the VirtualBox vm is almost unbearable, takes about 2 minutes to load any admin page, which is grinding content editing to a virtual standstill. My colleague utilising the same project on a Mac sees load times only marginally slower than a live install ( a few seconds).

Has anyone else had any experience with a similar issue using a virtualbox development environment? I’m starting to think I might be better installing mysql locally and running with IIS, but would like to keep the development environment consistent with the live environment so trying to avoid going down this root.

Viewing amendments made to the theme files is fine, as the browsersync works great, it’s just any work that needs to be done in wordpress admin that is painful. This is running with 4gb ram and 4 cpus assigned to the vm running a single site (so pretty sure that isn’t really the issue!)

Any hints greatly appreciated!

Hopefully your problems should disappear when Virtualbox 5.0 is released.

That’s interesting, hope that is the silver bullet, could do with trying to find a workaround before then, performance is so slow as to almost be unusable. Will update if I find anything that leads to a root cause of poor performance.

Love the setup of Roots as a whole, thanks to all who have made this project! Just need to find a way around this sticking point…

I’m using Ubuntu on the desktop and although Virtualbox is not exactly fast, it is at least usable.

A windows using friend of mine added an extra internal SSD to his rig just for Virtualbox and that seems to work well.

Not sure how that would work with Vagrant though.

1 Like

You can also try using VMWare instead of virtual box. I know VMWare is fast on windows. http://www.vagrantup.com/vmware

1 Like

Thanks for the advice, will take a look at that

Now setup using VMWARE instead of Virtualbox the difference is massive, I’d say about 100x faster, load times around a second now, as opposed to minutes before. Might actually start being productive now!

Had to work my way through a few issues, so for anyone else who is attempting this.

You’ll need to obviously amend the default provider from virtual box in the vagrantfile…

ENV['VAGRANT_DEFAULT_PROVIDER'] = 'vmware_workstation'

The roots/bedrock box isn’t found. I used the following

config.vm.box = 'mevansam/chef-ubuntu-14.04'

This box has a fix in place that resolves an issue with setting up the vmware shared folders, it’s a problem with the loading of vmware tools. I did find I have to do a vagrant reload, as the initial vagrant up fails to set this up, haven’t quite worked the resolution to this out as yet.

In the windows.sh file I also had to add a line before the “Adding ansible respitory” to the repository to be added. This for me was line 18 in Windows.sh

  sudo apt-get -y install software-properties-common python-software-properties

The speed issues with virtualbox on windows is all down to the shared folders, as above it is a massive difference switching to VMWARE. There is a cost for VMWARE and for the Vagrant plugin, but the benefit is huge on windows.

Whilst still grappling with the vmware setup, I did find another article referring to getting nfs for vagrant running on windows. This has potential to resolve the issue, but as I had already paid out for the Vagrant vmware plugin, I have yet to try this! Article is http://www.jankowfsky.com/blog/2013/11/28/nfs-for-vagrant-under-windows/. I may try this on my laptop with the Virtualbox 5 release candidate which recently became available, to see if this can also resolve problems. The inability to use nfs appears t be the key performance issue running on windows.

4 Likes

It seems adding nfs for vagrant on windows plugin has almost as great a positive effect, as the switch to vmware. To add this I needed to install the plugin

$ vagrant plugin install vagrant-winnfsd

And amended the VagrantFile to set the synced_folder call for windows to use nfs

config.vm.synced_folder local_site_path(site), remote_site_path(name), owner: ‘vagrant’, group: ‘www-data’, mount_options: [‘dmode=776’, ‘fmode=775’]

becomes…

  config.vm.synced_folder local_site_path(site), remote_site_path(name), type: 'nfs'

Would make sense to update, to only use this option for Windows users, it is so much more performant. I’ll try and put together a suitable update to cater for this

3 Likes

Hey thank you @matth for tips but got and error when i try to vagrant up :

[NFS] Status: running
==> default: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'vers=3,udp,nolock' 192.168.50.1:'/C/Users/Rom/Documents/PRO/DEV
/domain' /srv/www/domain.com/current

Stdout from the command:

Stderr from the command:

stdin: is not a tty
mount.nfs: access denied by server while mounting 192.168.50.1:/C/Users/Rom/Documents/PRO/DEV/domain

Have you an idea ?

Very strange, I am now having the same issue, yet to discover a fix. Did you find a solution @RomainJM?

Perhaps unsurprisingly this seems to have been a permissions issue for me… note to self : if all else fails try reading the error message! I’m not sure what the correct permissions need to be on the site folder, but opening it up to everyone on Windows certainly seems to have got things moving again.

No, i don’t found a solution. For the moment, i use default file (limited performance) for test other thing (environments, deploy, etc)

Did anyone work out a solution for this?

I’ve installed vagrant-winnfsd and have modified the synced_folder to use nfs and now trying to vagrant up it just seems to hang at:

default: Mounting NFS shared folders…

I’ve looked at windows permission and given the trellis folder full access to all users which made no difference.

Any ideas?

@matth Did you end up going with vmware? I have been trying for a few days now to make this work and you seem to be the only one who has done so with VMware.

This seems to be the point where I am running into trouble using mevansam/chef-ubuntu-14.04 .

INFO subprocess: Starting process: [“C:\Program Files (x86)\VMware\VMware Workstation/vmrun.exe”, “list”]
INFO subprocess: Command not in installer, restoring original environment…

This is how I have mine setup. The ONLY issue I have is when there a lot of images in the uploads folder. It gets stuck in an endless loop. That only happens on the first provision locally. In cases like that, I just delete all contents of my uploads folder, and when the provision is done, I run a YAML file to sync the local environment again.

I have considered opening a bug on that one instance, but not sure who to open it with. :stuck_out_tongue:
Outside all of that, it works NFS works flawlessly for me.

if (Vagrant.has_plugin?('vagrant-bindfs') && Vagrant.has_plugin?('vagrant-winnfsd'))
  config.vm.synced_folder local_site_path(site), nfs_path(name), type: 'nfs'
  config.bindfs.bind_folder nfs_path(name), remote_site_path(name), u: 'vagrant', g: 'www-data', perms: "u=rwx:g=rwx:o=rwx"
else
  config.vm.synced_folder local_site_path(site), self.remote_site_path(name), owner: 'vagrant', group: 'www-data', mount_options: ["dmode=776","fmode=775"]
end
1 Like

wowowowow

huge difference for me as well. pages were taking 15-30 seconds to load. now it’s under 5 seconds.

thank you for this

This did the trick! Thx a lot!

That was still too slow. Using rsync works fine for me.

In Vagrantfile I replaced
# config.vm.synced_folder local_site_path(site), remote_site_path(name), owner: 'vagrant', group: 'www-data', mount_options: ['dmode=776', 'fmode=775']

with
config.vm.synced_folder local_site_path(site), remote_site_path(name), type: 'rsync', owner: 'vagrant', group: 'www-data'

There’s a bug in vagrant rsync though, find the fix here: http://github.com/mitchellh/vagrant/issues/6702

Rsync is great in terms of performance, but the unidirectional sync causes you to loose a lot of the benefit of using a VM, especially if like me, you don’t want to run Node on your host.

The solution I’ve added to my Trellis setup is to have two synced locations for each site, one using standard vbox shared folders, and the other using rsync (in conjunction with the vagrant-gatling-rsync plugin).

This way, I can still use the VM’s dev tools (npm, capistrano, wp-cli etc) on the code in the share, but I can also edit the nginx config to point to the rsync location, which is the blazing fast. If I want to get any files back from the rsync location then I just copy them between the locations inside the VM.

Nowadays I’m working on Ubuntu, but even here, with the VM on an SSD, I see a huge performance improvement.

Having a large number of projects configured like this uses a lot of diskspace on the VM, and the shared folder performance seems to get worse with too many files being managed. So the solution is to allow the share/sync to be selectively enabled in the wordpress_sites.yml file. The code for this (in the Vagrantfile) is:

    wordpress_sites.each_pair do |name, site|
      if site['vagrant_share'] == true
        config.vm.synced_folder local_site_path(site), remote_site_path(name), owner: 'vagrant', group: 'www-data', mount_options: ['dmode=776', 'fmode=775']
      end
      if site['vagrant_sync'] == true
        config.vm.synced_folder local_site_path(site), remote_site_local_path(name), type: "rsync", owner: 'vagrant', group: 'www-data', rsync__exclude: [".git/", "node_modules", "uploads/"], rsync__args: ["--verbose", "--archive", "--copy-links"]
      end
    end

Then add vagrant_share and vagrant_sync variables to each project in your wordpress_sites.yml. (note that I don’t sync the uploads dir due to space constraints - instead I manually symlink it inside the VM if I need it)

And for anyone having trouble installing NPM becase of the Windows share issues, with this solution you can run npm install in the rsynced location and then symlink the resulting node_modules from the shared location. Now you can run gulp on the shared location (and commit the output to your GIT repo).

4 Likes