Difference between revisions of "stoney conductor: VM States"

Latest revision as of 17:00, 27 December 2013

Naming of VM states (the second state is only needed for special cases). The following attributes need to be read:

• sstStatus: Located directly in virtual machine leaf.
• sstVirtualMachineMode: Located directly in virtual machine leaf.
• sstProvisioningMode: Located in the virtual machine backup sub tree(s).

See the descriptions in the document stoney conductor: OpenLDAP directory data organisation in the chapter Virtual Machine and Virtual Machine: Backup for details.

Virtual Machines

Naming of VM states (the second state is only needed for special cases), valid for VMs:

Possible future states:

• Crashed (when vm should be running, but there isn't a QEMU process around)
• Frozen or Non responding (requires QEMU guest agent or a watch dog)

Future editing:

• Certain values like disk, cpu and memory will be able to be changed, even if the vm is running.

Tool-Tips:

• "stopped, streaming (without the percent status)": Show streaming information with vm-name(s) and percent status.
• Save text of Tool-Tips in language files.

VM Templates

Naming of VM states (the second state is only needed for special cases), valid for VM Templates.

Since VM Templates are basically VMs with additional metadata and can be cloned from, most of the runtime states are the same as for VMs and therefore not explicitly copied below and the respective entries are shaded    .

Please keep the Lean Provisioning documentation in mind for displaying the proper action together with the explanations in the Virtual Machine document for the attribute sstVirtualMachineMode.

VM-(Sub)States (streaming, backing-up, ...) and Machine Modes (ready to use, maintenance, ...) are orthogonal concepts even though they are not shown as such in the table below. Permit an action only if both VM-State and Machine Mode permit it (logical AND).

References

1. ↑ ^{1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22} Later. Should be implementable, but clarification needed on how it works.
2. ↑ ^{2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17} Later. Function can be made available partially. For example: Editing the name, description or even IP of a VM may be always possible, while changing the memory and/or disk size depends heavily on the state of the VM.
3. ↑ ^{3.0 3.1 3.2} A user connected to the VM can take this action despite being unavailable in the web-interface.
4. ↑ While the action is possible, the result may not be satisfying, most probably due to race conditions.