Home / server / Questions / 171213
Accepted
Adam
Asked: 2010-08-17 17:23:34 +0800 CST

How to manage changes to set of cloned Virtual Machines?

  • 772

I am trying to set up a workable model for development. I'm wondering if anyone has recommendations for Virtual machine software and what process to follow to enable the following:

  • Developers grab a copy of the gold image of a virtual machine and run the VM guest on their own workstations. (Ideally I dont want to pay for server hardware/software to host VMs centrally when developer workstations have all this horsepower that is idle)
  • The gold image of the Virtual machine is updated - using differencing disks, snapshots, or equivalent feature in the VM vendor of choice - each copied developer VM is updated with the new changes (Ideally I am not deploying an entire image - just the diffs from the gold image)
  • Is free (maybe wishful thinking)
  • As mentioned before - isnt a server-based solution (other than storing the gold image and diffs on the network somewhere) - I dont want more servers and software to manage
  • Must support 64-bit guests (Virtual PC and MS Virtual Server are out...)

Is this a pipe dream?

Given my constraints I think I can choose either VMWare Workstation or VirtualBox. But I dont think they will do exactly what I want.

As a compromise - could I use Hyper-V or ESX to create VM templates, create many clones of the templates - and somehow distribute those clones to individual workstations?

My idea with deploying differencing disks/snapshots is that this is practical on a weekly basis - to deploy an update to each individual developer VM that is then merged with the base image. The 'gold image' would then have the diffs merged too - so that all VMs would match without going to the trouble of deleting the existing clones, and cloning from an updated template. You could just keep running the same Vm - just keep applying differncing disks/snapshots.

virtualbox virtual-machines vmware-workstation

2 Answers

  1. Best Answer

    Snapshots: Preferred Approach

    1. Create a base VM on your machine. For your purposes, you will be perfectly fine using a compact/thin-provisioned disk image file, so don't use a fixed-size one.

    2. Shut down your instance of the base VM. (Suspend/hibernate is not sufficient.)

    3. Take a snapshot.

    4. Distribute it to the developers after you have taken the snapshot.

    5. When the time comes, fire up the base VM and update it. Any changes that you make will be written to new "delta" files, which will only be as large as the accumulated changes made since you took the snapshot. Because you have taken a snapshot, that enormous disk image file will remain 100% unchanged.

    6. Shut down your instance of the base VM. (Suspend/hibernate is not sufficient.)

    7. If you have made major changes (e.g. installing a large service pack), consider taking an additional snapshot now so that you will not have to re-transfer the current snapshot when you make your next update.

    8. Overnight, (a) either reboot each developer machine or programmatically kill the hypervisor process on each developer machine (no, the developers will not remember to close it themelves) and then (b) copy over the changed files using ROBOCOPY /MIR or the like.

    Of course, in order for this to work, you will need to transfer all changed files associated with the VM, which may include configuration files containing metadata about the snapshots in addition to the snapshot/delta files themselves. You also will need to ensure that, on each developer machine, the VM is stored in exactly the same location as it is on your own machine.

    Rsync: Alternate Approach

    An alternative approach would be to use fixed-size virtual disks, no snapshots, and an rsync client/server like DeltaCopy to copy only the changed portions. This is not the preferred approach because:

    1. It would require installing the rsync software on each developer machine.

    2. The actual copy process would take longer, despite no more data being transferred, because rsync would need to analyze the entire virtual disk file file to determine which portions need to be transferred.

    Conclusion: You could use rsync for this, but it seems like overkill if your hypervisor supports snapshots.

    • 3

  2. this sounds like you need a configuration management tool. this would be a central repository where you safe the configuration and clients (your windows vms) can get new configurations.

    as i'm using linux, i'm not sure how smooth this runs with windows, but there are solutions out there supporting windows. take a look at this wiki article. it has a nice sum up.

    • 0