| layout |
|---|
default |
A VM can find itself on a number of different states. Each of those states have a name and a meaning. The state a VM is in also determines the set of states it can move to. Example state names are: PROLOG, BOOT, RUNNING...
An action triggers a state change. These actions can be triggered by a user on the UI or by the environment itself. Example action names are: create, terminate, resume... You can see most of these on the UI:
Note:
We recommend you mainly use the following actions for managing your VMs:
- Terminate: the VM will shut down gracefully. Click the dust bin button and then Terminate.
- Undeploy: the VM's OS will perform a shutdown, the VM keeps its changes for the next Resume action.
- Stop: the VM keeps its changes for the next Resume action. Click on the pause square button and then Stop.
- Resume: resumes a STOPPED VM. Click on the play button. It will bring a VM from STOPPED or UNDEPLOYED to RUNNING state.
If you ever find a VM in a status that these actions cannot trigger any further changes, you may want to contact us at [email protected].
As long as a VM exists, it draws from your quota. Some states may be deceiving as they delay the moment that this quota is drawn from. The only way to prevent a VM from drawing from a quota is to Terminate it.
Overview:
| Command | OS action | non-persistent disks | resources | resume OS action |
|---|---|---|---|---|
| Terminate | shutdown | changes are lost | all free | n.a. |
| Undeploy | shutdown | saved to redundant storage | free except IP address | boot |
| Stop | none | saved to redundant storage | free except IP address | none |
| Suspend | none | stay on host | stay in use | none |
| Poweroff | shutdown | stay on host | stay in use | boot |
The play button can only be clicked when the VM is in state SUSPENDED or STOPPED. It resumes the VM to bring it to RUNNING.
Under the pause button you can find the following actions:
- Suspend
- Stop
Can only be triggered when the VM is in state RUNNING.
Suspend brings the VM to the SUSPENDED state, but first going through the SAVE state. The context of the VM is saved in the node where it is running.
This state keeps blocking the resources that the VM holds, so your quota keeps ticking.
The OS running on the VM does not notice anything. Persistent and non-persistent images will keep their changes for the next Resume action. If the VM is deleted in this status, non-persistent images will lose their changes, but persistent images will keep their changes.
When you Resume the VM (with the Play button), it is immediately restored: first it will go to BOOT and then RUNNING. The OS and processes will continue running from the point they were left.
Can only be triggered when the VM is in state RUNNING.
Stop brings the VM to the STOPPED state, but first going through the EPILOG state. The context of the VM is saved in the system datastore.
This state releases the resources that the VM holds, so your quota does not tick. You keep your IP addresses.
The OS running on the VM does not notice anything. Persistent and non-persistent images will keep their changes for the next Resume action. If the VM is deleted in this status, non-persistent images will lose their changes, but persistent images will keep their changes.
When you Resume the VM (with the Play button), it is not immediately restored: the scheduler must allocate resources again (the PROLOG state), then it will go to BOOT and then RUNNING. The OS and processes will continue running from the point they were left.
Under the power button you can find the following actions:
- Poweroff
- Poweroff hard
- Undeploy
- Undeploy hard
Can only be triggered when the VM is in state RUNNING.
Poweroff brings the VM to the POWEROFF state, but first going through the SHUTDOWN_POWEROFF state. The context of the VM is not saved.
This state keeps blocking the resources that the VM holds, so your quota keeps ticking.
The OS running on the VM receives the corresponding ACPI signal, so that it can shut down gracefully. Persistent and non-persistent images will keep their changes for the next Resume action. If the VM is deleted in this status, non-persistent images will lose their changes, but persistent images will keep their changes.
When you Resume the VM (with the Play button), it is immediately restored: first it will go to BOOT and then RUNNING. And the OS will boot again.
Can only be triggered when the VM is in state RUNNING.
Poweroff brings the VM to the POWEROFF state, but first going through the SHUTDOWN_POWEROFF state. The context of the VM is not saved.
This state keeps blocking the resources that the VM holds, so your quota keeps ticking.
The OS running on the VM does not notice anything. Persistent and non-persistent images will keep their changes for the next Resume action. If the VM is deleted in this status, non-persistent images will lose their changes, but persistent images will keep their changes.
When you Resume the VM (with the Play button), it is immediately restored: first it will go to BOOT and then RUNNING. And the OS will boot again.
Note:
You can use the state POWEROFF to change the capacity of your VM (if you have allowed this from the VM's template) by editing the CPU and RAM values under the Capacity tab of the VM's extended information screen.
Can only be triggered when the VM is in state RUNNING.
Undeploy brings the VM to the UNDEPLOYED state, but first going through the SHUTDOWN_UNDEPLOY state. The context of the VM is not saved.
This state releases the resources that the VM holds, so your quota does not tick. You keep your IP addresses.
The OS running on the VM receives the corresponding ACPI signal, so that it can shut down gracefully. Persistent and non-persistent images will keep their changes for the next Resume action. If the VM is deleted in this status, non-persistent images will lose their changes, but persistent images will keep their changes.
When you Resume the VM (with the Play button), it is not immediately restored: the scheduler must allocate resources again (the PROLOG state), then it will go to BOOT and then RUNNING. And the OS will boot again.
Can only be triggered when the VM is in state RUNNING.
Undeploy brings the VM to the UNDEPLOYED state, but first going through the SHUTDOWN_UNDEPLOY state. The context of the VM is not saved.
This state releases the resources that the VM holds, so your quota does not tick. You keep your IP addresses.
The OS running on the VM does not notice anything. Persistent and non-persistent images will keep their changes for the next Resume action. If the VM is deleted in this status, non-persistent images will lose their changes, but persistent images will keep their changes.
When you Resume the VM (with the Play button), it is not immediately restored: the scheduler must allocate resources again (the PROLOG state), then it will go to BOOT and then RUNNING. And the OS will boot again.
Under the reset button you can find the following actions:
- Reboot
- Reboot hard
Can only be triggered when the VM is in state RUNNING.
Reboot leaves the VM in the RUNNING state.
This state keeps blocking the resources that the VM holds, so your quota keeps ticking.
The OS running on the VM receives the corresponding ACPI signal, so that it can shut down gracefully. Persistent and non-persistent images will keep their changes after the reboot because the VM is not deallocated.
The OS will go through a graceful reboot sequence.
Can only be triggered when the VM is in state RUNNING.
Reboot hard leaves the VM in the RUNNING state.
This state keeps blocking the resources that the VM holds, so your quota keeps ticking.
The OS running on the VM does not notice anything. Persistent and non-persistent images will keep their changes after the reboot because the VM is not deallocated.
The OS will boot again.
Under the table button you can find the following actions:
- Hold
- Release
Can only be triggered when the VM is in state PENDING.
Hold leaves the VM in the HOLD state. It is intended as a means to delay the starting of a VM.
This state does not grab any resources, so your quota does not tick.
The OS in your VM does not notice anything. No image will suffer any change.
Note:
You can create a VM directly in HOLD status upon instantiating a template, by checking the box Start on hold checkbox on the Create Virtual Machine dialog.
Can only be triggered when the VM is in state HOLD.
Release resumes the start-up of a VM, to bring it to the RUNNING state.
This state will grab resources normally and let the quota start ticking.
The OS will boot again.
Under the dust bin button you can find the following actions:
- Terminate
- Terminate hard
Can only be triggered when the VM is in state RUNNING.
Terminate eliminates the VM from the system in a controlled way, first going through the SHUTDOWN state.
This state frees resources that the VM holds, so your quota does not tick.
The OS running on the VM receives the corresponding ACPI signal, so that it can shut down gracefully. Non-persistent images will lose their changes, but persistent images will keep their changes.
The OS will go through a graceful shutdown sequence.
You cannot resume this VM; you can only instantiate its template again.
Note:
If your VM is not reacting to the shutdown command from the cloud web interface, see VM not reacting to Shutdown.
Can only be triggered when the VM is in state RUNNING.
Terminate eliminates the VM from the system, first going through the SHUTDOWN state. No check is made if the VM actually reacts and shuts down. The OS running on the VM is terminated immediately and does not get a chance to properly shut down. As usual with a shutdown, non-persistent images will lose their changes, but persistent images will keep their changes. The state of the disk data may be corrupted, however, due to possible caching by the OS.
This state frees resources that the VM holds, so your quota does not tick.
You cannot resume this VM; you can only instantiate its template again.