- 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.
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.
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 :)
Disabling options like Application sharing, Drive sharing, video card 3D support, and the like will help. If you dont need it, turn it off.
- 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).
kernel/Documentation/cgroups/memory.txt circa line 255
I would like to point out a few things.
1. Another thing to set up.
Streamlining project setup is one of Vagrant's primary goals. Instead of putting someone, who potentially has no background with the app, through a 20 step process installing all the application dependencies you can simply tell them to run a few commands.
2. It's a "Ruby tool".
While I don't think your intention was to pigeon hole it, Vagrant is really meant for any development environment/language/setup. Its just unfortunate that the only supported provisioning tool uses Ruby for its DSL (are there similar tools in other languages?)
(NOTE: its been a while since I contributed meaningfully to the project)
Since clicking on that just to read my comment can be annoying, I've copied it below as well:
=========================================================
Yes! Yes Yes Yes! Virtualization for development is extremely important and I'm glad you wrote this. Also, thanks for the hat tip to Vagrant, I appreciate it. I've given a few talks on this and it always amazes me how many people are so comfortable with the status quo of developing on their own machines with apache/mysql/etc installed directly on their machines. Its a disaster waiting to happen.
I want to point out to the many people using VMWare out there: VMWare Fusion is great, yes, I won't argue. Their shared folders are better, again I agree. But Vagrant does make use of NFS which is faster than even VMWare Fusion's shared folders in order to get around VirtualBox's terrible performance.
And just because I have things to say, here are a few of my own remarks against the arguments against virtualization of development:
* Speed - Given enough RAM (which for a standard web application, shouldn't be any more than 512 MB to 1 GB for the VM instance), the speed difference is noticeable but not detrimental to your productivity. For regular web requests you won't notice any speed difference. For CPU intensive background tasks, you'll probably see a 1.5x slowdown. Again, unless you're running 5 hour tasks during development, it shouldn't be a big deal, and the benefits outweigh these issues, in my opinion.
* Lower level than you're used to - Then get your friendly sysadmin to setup a base image to use for your site. A modern sysadmin has many scripts made to automate the setup of the environment for production. There is no reason these scripts can't be used to setup your development as well. Use it! Stay in your happy place and just boot up a VM and code! (Although its my opinion every developer should take the time to learn their software stack top to bottom)
* Something else to setup - Once. You only need to learn it once, and its repeatable and dependable. I would argue that setting up a new software stack every time a dependency changes on your web app is far more than one more "something else to setup."
* Developer workstations should be personal - Right! I agree 100%. So stop installing server crap on your personal computers. Keep your Twitter clients away from your web servers. Use a VM and keep your workstation personal.
Thanks again, Mitchell
Regarding tools other than Chef for provisioning, while there is a Python clone somewhere Chef will very likely have the ability to use other languages for recipes very soon. I've seen at least Java and Python mentioned.
It's my understanding you can do it, but it's a bit hacky, right?
I have a pretty capable machine (Core i7 920, 6GB, GTX260 video card), but speed wise it is quite usable and I run all sorts of osx-only apps on it (like the omni suite) every day.
So.. i guess like 7.5 out of 10? Buggy, but really getting close.
That being said, if you're trying to target Mac or Windows, it's generally a good idea to use that specific platform's tools. It's reasonable to develop Windows and Mac apps on Linux but it may not be the best environment to do so. It's really up to you as a developer to determine the best toolchain and processes based on what you're trying to accomplish.
Certainly not the default HFS+, which is is case-insensitive but case-preserving.
I've tried using a VM for doing development, but I've run into the issues mentioned in the parent article: Visual Studio 2010 is memory and CPU hog. I've maxed out the RAM in my laptop, and it still ran too slowly to be really useful.
In addition, if you get a little too clever and accidentally wipe out something crucial in your environment, you just spin up a new VM. It's a tremendous timesaver.
That way you can set up servers, experiment with new platforms and/or applications, hack^Wlearn config files and system internals, etc. without risk of bogging down or blowing up your machine and having no recourse but a full reinstall and reconfig.
I've got core Ubuntu Server, OpenSuse, and CentOS server images, that include extras like git-core, htop, ssh, and a few other utilities I universally depend on, and that I can copy, deploy, and configure for whatever specialized purpose that comes up.
<3 it.
It makes for very convenient testing and it has helped me catch issues others didn't see on their distros, mostly because CentOS has ancient versions of everything and sometimes people don't realize they are relying on a feature that was introduced later.
