Hacker News Reader

Hacker News

Comment by JofArnold | Hacker News Reader

Full thread

JofArnold

Not strictly in the spirit of the post, but I use a nice VM setup I thoroughly recommend:

- Host: OSX (2.4GHz i5, 8GB ram)

- Guest1: Ubuntu 10.10 (1.5GB ram allocated; acts as a LAMP server, available to Host and other Guests)

- Guest2: WinXP (1.5GB ram allocated - I use it for IE and for Xara)

This config eats RAM, but affords so many advantages:

1/ Makes my LAMP server portable. Can set up on new computer in no time

2/ Means I can experiment with server software and can revert when I break something

3/ Enables easy cross-PLATFORM browser testing which is vital if you care about fonts and pixels

4/ Can easily fake slow internet connections etc for web dev

5/ Gedit :P

6/ Nautilus :P

Major disadvantage is filesystem access speed.

View on HN

PS, if anyone knows a solution to the file access speed issue (not just the filesystem of the guest, but also what ever you share with it from the host) please tell me. Parallels, VMWare Fusion and VirtualBox all have this issue and it drives me mad sometimes!

I'm not sure if this helps in your situation, but when I'm running VMware I don't share any local directories. I use rsync to manage the virtual server directories since it's similar to how I deploy to my remote servers.

Having to manually "deploy" code to a local virtual server can be tedious, so running a background process that watches your local directories for changes helps a lot.

Can you elaborate on that background process? Is that something built into rsync?

It's actually something I've been working on that I want to put up on github. I hacked up a Python version of it as a proof-of-concept but rewrote it in C as an installable executable using autotools.

Basically I tell it which directory I want it to watch for changes and it does automatic syncing by piping rsync. I keep a local and remote signature of the files and their timestamps. When it first starts up, it pulls the server sig file and compares it to the local one. If there's a mismatch, the server is updated. From there it manages the signatures locally until they're different.

Writing the sig file to the remote server is done in the same rsync pass because it's stored in the local directory as a dotfile.

I realize rsync does its own checksums, but using my own crude signature files makes it so I don't have to keep calling rsync. I only call it when something changes.

I also have some stuff I'm working on that ties into auto-restarting servers when syncing finishes, rolling server deployments for no downtime, db migrations, etc.

Sounds like some pretty cool stuff! I hope you post about it when you do decide to release it. :)

I understand you use the rsync approach since its similar to how you actually deploy, which is completely understandable, but I just wanted to note that John and I struggled with the shared folder performance issue + Vagrant for months, and we did a LOT (months) of real world tests with various solutions (John at one point even integrated background automated rsync directly into Vagrant), we found that NFS is really the only satisfying solution (for us, at least).

NFS allows us to edit code locally on our host, and have it "instantly" be ready on the guest. After just half an hour of working, the various inodes are cached on the guest and file system access over NFS is mostly native-speed since it only needs to grab changed pieces.

The end result: We completely ripped out background rsync despite John working weeks on it, and we put in built-in support for NFS, which has been going strong since around July now and is happily at work at many places that use Vagrant :)

People might be interested in DoubleDown (http://blog.devstructure.com/introducing-doubledown) from the DevStructure guys. It uses rsync in a similar background manner and it's designed with this exact problem in mind.

SSD will help make it faster, but the OS will also be that much faster so it won't seem faster by comparison, only in an absolute sense.

From the experience I've had with running Parallels and the like, I disable any sharing of drives. I dont need drag and drop files from and to each one. After disabling that, I see better performance.

Disabling options like Application sharing, Drive sharing, video card 3D support, and the like will help. If you dont need it, turn it off.

Vagrant automates the shared folders through nfs to work around VirtualBox's abysmal performance.

I use a similar setup.

- Base: OSX (3.06 GHz Core 2 Duo, 8 GB RAM, 500 GB HDD)

- Guest 1: Windows 7 3 GB RAM, for VS 2010, for Silverlight development

- Guest 2: Win XP 512 MB RAM - for testing with IE6

- Guest 3: Ubuntu 9.04 (need to update)

This works really well, and Win 7 is snappy and VS 2010 works flawlessly. On OSX I always have Chrome, AntiRSI, Things, TextMate, Terminal, NetNewsWire and iTunes open.

A big advantage is that I can fearlessly install things on Windows, I simply back up the VM before any installs/updates.

This config does work pretty well, except 8GB RAM does fall short sometimes. In my experience, VM performance takes a nose dive the moment OSX starts swapping, this is something I watch and now have to re-boot almost everyday (gone are the month long sessions).

Reply on news.ycombinator.com