Virtual Machine Sprawl

I've stopped using Virtual Machines because they are too useful. Kind of like Yogi saying of a restaurant, nobody goes there anymore because it is too crowded.

Actually I have just reached limit of the number of Virtual Machines I can track and have stopped creating and using additional virtual machines.

So Virtual Machines have crossed over the point where their own success is the problem. This problem has picked up the name Virtual Machine Sprawl. The sprawl problem creates four problems; space, providence, version control and restoration or setup speed.

Each virtual machine takes megs of space in the most compact form and in most cases after a few software installs they are up to gigs of space. I have found I need VMs for several OSes and for each OS I need a range of software installed and not installed and combinations in between. So before I know it I am up to 100s of gigs of space needed.

Providence refers to the prior history of the VM. Wear refers to this as the Genetic Makeup of the Virtual Machine. What is important here is not just what is installed but often the order it is installed. Every ASP.NET programmer is now familiar with the slight difference between installing IIS first then Visual Studio and installing Visual Studio first and then IIS.

Just like code there must be some mechanism for keeping original untouched copies of the machines. Unlike code, nearly everything you do with a virtual machine starts to change it. A primitive solution is to keep a directory full of copies. Unfortunately this instantly doubles the space requirements and there is nothing to prevent the machines being opened and thus spoiled.

Assuming you have found mechanism to track providence and another to track version you will still need to throw away your current copy and restore it from version control. As gigs are involved, the copying can take a chunk of time.