I have thought for some time that it would be fun to learn fencing. Today I found out what can make fencing a VM so helpful.
A bit of background: We have a VMWare virtual machine farm. Someone sets up a VM with one of the nightly builds, and then developers or testers can clone those VMs for their own testing. Nice! The one snag is the IP address – if you simply clone the machine, the address will conflict with every other clone on the network. There are two ways around this.
The unfenced route:
- Discard the state of the config
- Open the config and go to Properties of the VM
- Delete the NIC and add a new one
This has the disadvantage, though, of you having to discard the state of the machine first (having the effect of setting it back to a power-off state? something like that?) All other things being equal, this would not be a big hardship, but when we’re testing on nightly builds, the system can be a bit fragile (ok, really fragile) and there can be issues restarting all our subsystems and getting them into a happy enough state to test. Whoever it is that sets up the VMs from the nightly builds gets the subsystems running and that’s the state in which they save the VM. I was losing that work when I discarded state to go the unfenced route. Then I had to spend time getting the subsystems running myself. Waste o time!
Instead, when you deploy the VM you can just check the Fenced box, and then the server farm somehow does address translation, finding an IP address unused by any of the other clones. Thus you don’t have to go to the minor work of deleting and re-adding the NIC, and more importantly (for us anyway) you also don’t have to discard the state and redo someone else’s work getting the system into a stable state for testing. Nice!