views:

394

answers:

6

Lately I have been thinking about investing in a worthy USB pen drive (something along the lines of this), and install Operating Systems on Virtual Machines and start developing on them.

What I have in mind is that I want to be able to carry my development boxes, being a Windows Distribution for .Net development and a Linux Distribution for stuff like RoR, Perl and whatnot, so that I would be able to carry them around where need be...be it work, school, different computers at home etc...

I am thinking of doing this also for backup purposes...ie to backup my almost-single VM file to an external hd, instead of doing routinely updates to my normal Windows Box. I am also thinking about maybe even committing the VM boxes under Source Control (is that even feasible?)

So, am I on the right track with this ? Do you suggest that I try to implement this out?

How feasible is it to have your development box on Virtual Machine that runs from a USB Pen-Drive ?

A: 

Check out MojoPac:

http://www.mojopac.com/

Hard-core gamers use it to take world of warcraft with them on the go -- it should work fine for your development needs, at least on Windows. Use cygwin with it for your unix-dev needs.

Ish
+1  A: 

Hopefully you are talking about interpreted language projects. I couldn't imagine compiling a C/C++ of any size on a VM, let alone a VM running off of a USB drive.

Nick Stinemates
+1 VM or any OS running off any solid state is/can be a nightmare, from VM to cygwin.. you can **try** but you should steer off..
Ric Tokyo
+1  A: 

I do it quite frequently with Xen, but also include a bare metal bootable kernel on the drive. This is particularly useful when working on something from which a live CD will be based.

The bad side is the bloat on the VM image to keep it bootable across many machines .. so where you would normally build a very lean and mean paravirtualized kernel only .. you have to also include one that has everything including the kitchen sink (up to what you want, i.e. do you need Audio, or token ring, etc?)

I usually carry two sticks, one has Xen + a patched Linux 2.6.26, the other has my various guest images which are ready to boot either way. A debootstrapped copy of Debian or Ubuntu makes a great starting point to create the former.

If nothing else, its fun to tinker with. Sorry to be a bit GNU/Linux centric, but that's what I use exclusively :) I started messing around with this when I had to find an odd path to upgrading my distro, which was two years behind the current one. So, I strapped a guest, installed what I wanted and pointed GRUB at the new LV for my root file system. Inside, I just mounted my old /home LV and away I went.

Tim Post
A: 

This article on USB thumbdrives states,

Never run disk-intensive applications directly against files stored on the thumb drive.

USB thumbdrives utilize flash memory and these have a maximum number of writes before going bad and corruption occurs. The author of the previously linked article found it to be in the range of 10,000 - 100,000 writes but if you are using a disk intensive application this could be an issue.

So if you do this, have an aggressive backup policy to backup your work. Similarly, if when you run your development suite, if it could write to the local hard drive as a temporary workspace this would be ideal.

Simucal
the write cycle issue is now into the low millions - which is better, but still an issue in a situation like this
warren
I find the whole maximum writes scare story to be overblown. The maximum erase/write cycle count is "per block", and decent drives will do wear-levelling. What's more, if a Flash block does die and wear-levelling is not there or exhausted, then it simply becomes read-only. You probably won't lose the data. They will not only outlast any floppy disk or DVD, they've a reasonable stab at outlasting a hard drive (given some hard drives die within a few months). Which isn't to say a USB flash drive will never die on you or you shouldn't backup, just that the panic stories are unreasonable.
thomasrutter
+2  A: 

I absolutely agree with where you are heading. I wish to do this myself.

But if you don't already know, it's not just about drive size, believe it or not USB Flash drives can be much slower than your spinning disk drives!

This can be a big problem if you plan to actually run the VMs directly from the USB drive!

I've tried running a 4GB Windows XP VM on a 32GB Corsair Survivor and the VM was virtually unusuable! Also copying my 4GB VM off and back onto the drive was also quite slow - about 10 minutes to copy it onto the drive.

If you have an esata port I'd highly recommend looking at high-speed ESata options like this Kanguru 32GB ESata/USB Flash drive OR this 32GB one by OCZ.

The read and write speeds of these drives are much higher over ESata than other USB drives. And you can still use them as USB if you don't have an ESata port. Though if you don't have an ESata port you can buy PCI to ESata cards online and even ESata ExpressCards for your laptop.

EDIT: A side note, you'll find the USB flash drives use FAT instead of NTFS. You don't want to use NTFS because it makes a lot more reads & writes on the disk and your drive will only have a limited number of reads & writes before it dies. But by using FAT you'll be limited to max 2GB file size which might be a problem with your VM. If this is the case, you can split your VM disks into 2GB chunks. Also make sure you backup your VM daily incase your drive does reach it's maximum number of writes. :)

Ben Daniel
A: 

I used to do this, and found that compiling was so deathly slow, it wasn't worth it.

Keep in mind that USB flash drives are extremely slow (maybe 10 to 100 times slower) compared to hard drives at random write performance (writing lots of small files to a partition which already has lots of files).

A typical build process using GNU tools will create lots of small files - a simple configure script creates thousands of small files and deletes them again just to test the environment before you even start compiling. You could be waiting a long time.

thomasrutter