Vagrant and Virtualbox = slow on Windows (update)


(lid) #1

###I decided to take the dive with the vm and it is slow … so slow

Update:

After leaving the browser for know how long finally the site went up, now that I have many object cached on the browser level, if i refresh the page it will take about two minutes for the page to load again

some background, I am running virtualbox and vagarant on host machine windows 8

on a side topic
Vagrant really need to get smarted when downloading assets and support resumeable downloads I had my box image download failed at 98% and a 200k download speed blah.

I followed the tutorial, and started the rails server

“bundle exec rails s”

tried my luck at the browser and all I got was blank page that is keep a loading status for ever
"http://localhost:4000"

I looked at the ssh window and this is the last log from the request

-07-03T02:20:12.948646 #25269] INFO – : Rendered common/_discourse_javascript.html.erb (25.6ms)
-07-03T02:20:12.950428 #25269] INFO – : Completed 200 OK in 8690ms (Views: 8593.6ms | ActiveRecord: 26.0ms)

Windows8
Virtualbox 4.3
Image installed on external drive (usb3)

Bottom line, the virtualbox pulls the source of discourse from a shared folder (virtualbox feature)
which I assume is where the slowness is coming from, applying this fix did not help much
http://www.virtualbox.org/manual/ch12.html#idp56302608

And i am still getting a blank page, Any idea why?

I have noticed this error in the log when first running “bundle exec rails s” startup
"failed to create symbolic link `/vagrant/public/plugins/emoji’: Protocol error"

So who is using the combination of vagrant and virtualbox successfully ?

The all idea of having this setup is for hassle free installation for developers/contributors to start with their feet on the ground.

It is there and we need to make effort to make sure it is actually working or not having it at all.


Setting up Discourse on Vagrant and Windows
I can not set up a dev environment?
Windows / Vagrant and (Docker) for development
(Sam Saffron) #2

What spec computer are you on?

Are you able to check out the source locally in the vm and then work on that? I find that the “keep source on host” strategy is fatally flawed, we really need to change that.


(lid) #3

I am running on windows 8 /
cpu i7-4500u
memory 16gb
hd: internal and external for vm stuff

@sam , I actually didn’t try this approach yet, but it was next on my todo list.

@tuananh
I think my external usb 3 has sufficient power
External drive

Internal drive
Dr


(lid) #4

I am not sure the source on host strategy is totally flawed.

it does give the advantage for developers editing source files in the environment they are familiar with and the tools they are accustomed to.

The virtual environment that vagrant create is first of all headless there is no GUI ( can be changed on the vagrant config of course) but this is not the main concern.

I am thinking few possible solutions:

1. Setup a git repository on the host where the guest machine can checkout the code from.
this will allow local development without dependencies on external repositories.
the downside of this is that we are some what violating the host with the git daemon.

Workflow
user change source file on host
user commit changes to repositroy
host push changes to guest repository (via git protocol)
guest triggered to checkout master
guest checkout new source

2. set a git " server" repository on the guest, and have the host push changes to the guest repository

Workflow
user change source file on host
source is committed to local repository
host trigger guest checkout
guest checkout source from host repository

both 2 suggestions can porobably be based on one of the git protocols (git://)
http://git-scm.com/book/en/Git-on-the-Server-The-Protocols

How fast will the git protocol is, but at least we know we eliminate the shared folder setup


(Jeff Atwood) #5

Yes if you have ideas on this we can include them in our forthcoming Windows specific dev guide. Please do share what you learn and discover here and we will make it available to everyone.


(lid) #6

I already have some partial solution with option 1 ( guest checkout from host using git://)

I am currently trying to think of the best approach for the developer to trigger the guest machine to checkout the code.

I am thinking of expose a simple server that will listen for let say
http://guest/refreshcode
that will trigger the git checkout

And we can possibly create a git hook on commit on the host that will call that guest api

if you have better ideas let me know
I am going to play around with that idea above

I am also documenting my process


(Ole Vik) #7

I am also struggling with getting the vagrant properly running on Windows. You noted that you are also documenting your process, do you have a blog or similar that describes how you did this?


(Jonathas Spalding) #8

You should take a look at this post from the creator of Vagrant:

Also, there is a comment by Régis Hanol on this post from Discourse blog that suggests to use rsync to get a decent performace.

I have everything set up following the Discourse Vagrant guide, however it takes a ridiculously amount of time to load when trying to access Discourse via browser on the host machine. I believe this is caused by the shared folder bottleneck.

I will try to get this working with rsync later on and share how it goes with you.


(Mittineague) #9

Thanks for mentioning that rsync bit by @zogstrip . I was so lost in the install process I missed that when I went through the process.

My localhost is painfully slow. Though once it makes it to the first load in it isn’t so bad.

I upped the VirtualBox memory but that didn’t help any :frowning:

And a real PITA is that I haven’t yet gotten symlinks to work (Windows 7 Home Premium edition).

But I’m definately all for getting past the initial ~hour load in time.


(Jonathas Spalding) #10

Regarding the symlink issue, same here. I will try to run Vagrant/VritualBox with admin privileges.
Here’s the tip: windows - VirtualBox: issue with symlinks in shared folders - Server Fault


(Sam Saffron) #11

I just think it is completely crazy to try and keep the code on the host filesystem and use SMB or whatnot to run Discourse in the hosted VM.

Completely crazy.

If the code lives in a proper ext3/ext2/btrfs or whatever filesystem, stuff is fast.


(Jonathas Spalding) #12

I completely agree, Sam! :smile:

I have all up and running smoothly now just by following the additional steps from @zogstrip on the comments from this post

So, unless I’m missing something from the Vagrant setup tutorial, we are executing bundle exec rails s from the /vagrant directory, which is the shared folder that Vagrant mounts on VM startup (vagrant up) as seen below:

==> default: Mounting shared folders…
default: /vagrant => D:/project/discourse

I think this is the reason why we are getting an unusable performance (maybe VirtualBox is struggling to keep the shared folder in sync with the host?).

The downside is that everytime I change any file on /vagrant shared folder (including my changes on the host or git pull on the hosted) I must manually sync these changes to the non-shared folder from where I’m running Rails, calling the alias created with the steps from @zogstrip.


(Sam Saffron) #13

I don’t understand this philosophy of mounting folders in a vm, the filesystem is never EVER going to be correct it needs to emulate a bunch of stuff in a VM layer.

Kind of wish we just dropped vagarant altogether if mounting incompatible filesystems through a translation layer is a requirement.

I am using vmware to do all my dev, running on a windows 8 box, my source lives in an ext3 fs volume in the VM. Performance is spectacular. I use git command line or git gui to check stuff in, everything is happy.

If vagrant is a go, stuff needs to be mounted in reverse … have the vagrant fish the folder out of the VM onto the host or set up SMB in the VM and use a network share on the host.


(Berniegao) #14

have you proceed using the rsync and how is that going?


(Jonathas Spalding) #15

Sorry but no… I just moved on and now I’m using the official docker image
on a VPS.


(Mittineague) #16

I didn’t do the rsync but I’ve found that by using Chrome instead of my usual Firefox, for what ever unknown reason, things are much much faster.


(Oliverpool) #17

Hi,

I had the issue of Vagrant and Virtualbox being extremely slow on Windows and I just fixed it! (I didn’t test it for Discourse development, but it might be worth a try).

The solution comes from this forum: For those who find Homestead/Vagrant/Virtualbox slow on Windows

It’s just activating the NFS support on windows via the vagrant-winnfsd plugin (hence the source code stays outside of the Virtualbox).