Pattern - Transient Virtual Machines

Virtual Machines can be set up as with normal physical machines: all changes to the virtual disk are persisted for re-use. This is entirely optional. VMs can be set up so that all state built up during a run is discarded at the end of the life VM's life. This could be implemented in a number of ways:

1. Cloning the VM image for the livespan of the VM, destroying the files at the end of the run.
2. Only recording the changes between a template VM and the current run. This can be more efficient, as the cloning phase can be slow on a big disk image, and creates scalability problems if a single server is trying to host many machines.

Features

• All changes to the VM are lost when the VM is terminated.
• It is usually possible to bring up the VM template in persistent mode, so that system updates can be applied.
• A management interface allows the VMs to be restarted, rolling it back to the original state.
• Servers can be configured to restart automatically every night.

Advantages

• Eliminates the cost of having to maintain multiple, divergent system images.
• The base VM image can be created and configured by hand.
• Enhances front-end server security. If the web front end is hosted out of transient virtual machines, any exploited security hole will only remain exploited until the next restart.
• Allows untrusted applications to be run.

Disadvantages

• Applications need to be written knowing that no state can be persisted to the local filesystem.
• Per-VM state needs to be provided to the specific machines, somehow; with a common filesystem, this is difficult.
• If a front end server is exploited for only a few hours, damage can still be significant. There is no substitute for security.
• There are known ways for programs to determine that they are operating in a software-implemented virtualization environment, and occasionally security holes allow the code to get out of the VM.
• If the base VM is hand-created, it may be hard to maintain, and expensive to rebuild. This increases the maintenance costs of the base image.

This technique is the primary way to scale virtualized hosting. It is how EC2 hosts are deployed: a single image in the Amazon S3 filestore can be deployed to any number of servers. While state in the servers survives reboot, when then VM is terminated, the updates to the virtual file system are lost. The sole means of persisting state in the current (March 2008) file system are to write it back to the S3 Filestore.

SmartFrog support

• The CopyFile component can be used to copy VM images and configuration files prior to bringing up the system.
• The DeployByCopy component will not only copy a file on deployment, it will delete the copy when terminated.
• The EC2 components are adding support for Amazon EC2 server farms and the S3 Filestore.
• The sf-xmpp components can be used to allow machines to communicate with each other, without knowing network addresses in advance.