Too many VMs

As part of my work life I regularly need to run windows development software on my Mac. Typically for a client engagement. This is a really convenient setup. I can take a snapshot before I start work on something new and then at the end roll back to the original state ready to work on the next project.

One of the downsides I have encountered recently is the need to keep all these machines up to date with patches and other software updates that seem to be part of everyday life.

Don't get me wrong I think its great that we have this steady stream of updates to make things better but when you start multiplying this up for the VMs I have on my machine the effort to keep them up to date starts to be become a bit of a pain.

I think it is time to start rationalising to a smaller number - just so I can keep them up to date.

Virtuosity

For some time developers writing applications for managed virtual environments have been enjoying the benefits of being able to interrogate and control the and generate code at runtime. When used appropriately these additional elements have delivered significant advantages - particularly in the tools world. Mocking libraries would not be easy to implement in a non-managed environment.

In the world of build management we have seen an explosion of tools that make it easier to deliver components and applications into a production environment.

One element of the picture that we have not seen a lot of progress on is environment control and deployment. Currently there seems little support for automated environment setup or deployment testing.

Virtual Journys #1

For some time I have been a great fan of virtual hardware and the now opportunities it brings.

For most of this year I have been working on a large enterprise scale Java application targeting IBM WebSphere. Currently this configuration is only available on Windows and Linux so my Mac OS-X is out in the cold. During the day I work using windows and in the evening OS X for my own projects.

With the availability of Parallels and VMWare's virtualisation systems for the Mac new options are available. The most obvious is to create a Windows development envrionment for work running entirely in the guest Windows operating system. I thought I would try a different options. I would keep the source on the host OS X filesystem and perform builds using the virtual machine. Both Parammels and VMWare allow the host filesystem to be accessed as a network server. For windows this means that you can map the host files as a network mapped drive.

My first experiment used Parallels. The source was located on the host drive and I mapped a drive from the guest Windows system to the host source folder. I use helper batch files to move around the source and do tageted builds (e.g. bvt for ant -f custom-build.xml bvt) which seemed to be a problem for some reason. To run the CMD files I found I had to type bvt.cmd rather than bvt. It appears that the bvt is not sufficient to find and run bvt.cmd - very odd.

Otherwise things appear to work fine.

I exported the guest image using the VMWare importer tool to the host filesystem and booted the new VM in VMWare and set up the mapped drive in the same way. This time bvt was sufficient to find the bvt.cmd so there must be a difference in the way the shared filesystems work.

All the VMS are running on an external USB drive. Having the VMs there is convenient if I want to boot them on another computer and I find that the performance is faster with a second drive. I have used two types of drive. The first is a simple 160GByte laptop style drive which is convenient for travel. The other is a 150GByte 10,000 RPM raptor drive which is really sweet and I think faster indicating to me at least that USB is not the limiting factor for the slower drives.