Open Stack

On 10/28/2013 12:27 PM, Peter Feiner wrote:
> Thanks for the plug Jay :-)

You're welcome :)

> Let me explain a tiny bit:
>
> Step 1. Boot VM
> Step 2. Create "live image", which is a snapshot of disk, RAM, etc.
> Step 3. Boot from "live image"
>
> Instances booted from the same "live image" share RAM and start in the state they were snapshotted at in Step 2, thus skipping the OS boot and any common application setup you did beforehand.
>
> Therefore, Adrián, VMS addresses your problem not by having a pool of virtual machines ready to run, but by reducing virtual machine creation time (more precisely, reducing the time between requesting a new instance and the time it’s ready to start doing work).

Yes, this is an important point, because it highlights the difference 
between the VMWare vMotion [1] product and the concept described above 
of "fast-booting instances". In the former, the resources take up twice 
the capacity of a normal instance, since both instances are required to 
be up and running simultaneously in multiple vSphere hosts. In the 
latter, the VMS snapshots are not required to be running anywhere and 
only take up the disk storage required to store the disk/memory image 
snapshot. vMotion has the advantages of allowing complete in-memory 
failover, including the in-process memory and transactions in the source 
machine to the destination machine. If you don't want or need that, I 
would bet that the startup times of booting VMS images would be better 
than the 2 second failover time that vMotion advertises.

Best,
-jay

[1] http://www.vmware.com/products/vsphere/features-vmotion