3.8 VM Control: Manage Virtual Machine Instance State

****WORKING DOCUMENT****

3.8      VM Control: Manage Virtual Machine Instance State

Actors: cloud-subscriber, cloud-provider

Goals: A cloud-subscriber stops, terminates, reboots, starts or otherwise manages the state of a virtual instance

Assumptions: A suitable VM image (operating system executables and configuration data) exists.  Possible formats include OVF.

Success Scenario 1 (start-stop-non-persistent-VMs, IaaS):  A cloud-subscriber identifies a VM image to run.  The cloud-subscriber chooses a number of VMs and issues a command to load the VM image into the chosen number of VMs and execute.  The cloud-provider provisions VMs and performs the loading and boot-up cycle for the selected image for the requesting cloud-subscriber and initializes each VM with the cloud-subscriber's credentials (so the cloud-subscriber can log in). The provisioning includes the allocation of an IP address. The boot device (root file system) for each VM is non-persistent.  The cloud-subscriber may issue commands that connect persistent media as non-root file systems or non-file system devices for each of the VMs, operate the VMs to read or store data onto those devices, and then stop the VMs.  Upon a VM's exit, the contents of the boot device are lost but data written to other devices during the run is preserved.  The IP address for the VM is disassociated when the VM is stopped.  The cloud-provider charges the cloud-subscriber for cpu time, storage time, network usage, and possibly for system startup cycles.

Failure Conditions: (1) The VM image may fail to boot correctly; (2) VMs may fail to stop on command.  (Note that many network-level failures could be enumerated like, e.g., fails-to-obtain-a-valid-IP-address.)

Failure Handling: For (1), the cloud-subscriber can choose a different VM image, or debug; for (2) the cloud-subscriber can request the cloud-provider to terminate the stalled VMs.

Success Scenario 2 (start-stop-persistent-VMs, IaaS): A cloud-subscriber identifies a VM image to run. The cloud-subscriber chooses a number N of VMs and issues a command to load the image onto a persistent media (most likely a form of network-attached storage). The cloud-subscriber issues a command to boot N VMs from the persistent media, using the cloud-subscriber's credentials for each (so the cloud-subscriber can log in). The cloud-provider provisions N VMs, associates the persistent network storage with each as a boot device and initiates the boot sequence. The boot device is persistent and the data contents survive VM shutdowns. The cloud-subscriber may issue commands that connect additional persistent media as non-root file systems or non-file system devices for each VM, operate the VMs to read or store data onto those devices, and then stop the VMs.  Upon a VM's exit, the contents of all persistent devices are preserved.  The IP address for the VM is disassociated when the VM is stopped. The VMs can be restarted on command. The cloud-provider charges the cloud-subscriber for cpu time, storage time, network usage, and possibly for system startup cycles. The VMs can be restarted.

Failure Conditions 2: (1) The VM image may fail to boot correctly; (2) the intended persistent boot device may fail; (3) VMs may fail to stop on command. (Note that many network-level failures could be enumerated like, e.g., fails-to-obtain-a-valid-IP-address.)

Failure Handling 2: For (1), the cloud-subscriber can choose a different VM image, or debug; for (2) the cloud-subscriber can retry or consult with the cloud-provider; for (3) the cloud-subscriber can request the cloud-provider to terminate the stalled VMs.

Requirements File:  NA

Credit: Amazon