You can lock or protect a deployed VM when it is powered on, paused, or powered off.
To protect a VM
The platform will display a padlock symbol in the top left corner of the VM icon and change the status of the VM to MAINTENANCE. The administrator can customize this status in the UI labels.
The name of the administrator who blocked the VM and the reason display in VM details → General.
To release a protected VM, click the padlock unprotect VM button
Screenshot: the platform displays restricted virtual appliances with the label "Restricted". The platform does not display restricted VApps and their VMs and scaling groups to a user without the privilege to view them.
Users who can Manage restricted virtual appliances can select the Restricted checkbox when creating or editing a virtual appliance. For other users this checkbox will not display. Users with this privilege can work with VMs in restricted VApps.
To restrict a VM by moving it to a restricted VApp:
To relocate a VM:
Screenshot: Select the VM and click relocate
Screenshot: Host selection list
Screenshot: Host metrics and Relocate button
Screenshot: After relocation, the new host details are shown, for example, with a new Remote access address
Screenshot: You can also check the relocation by clicking the Relocate button again, which will show the original host as a new candidate
What happens when the user clicks deploy?
The VM scheduler deploys the VM.
A simplified description of the deploy process is shown in the following diagram.
The user and the administrator may be notified of the error.
The user can click on the error icon to display the events and the user can click on an event in the list to display its tracer message.
The platform displays the full details of an error in the Events view and on the Events panel in the Home view.
Here is an example of an event for a failed reconfigure.
The VM warning symbol is based on the VM task state. The VM tasks are a collection of jobs. For example, a Deploy task includes jobs to allocate, configure, and power on the VM. If a job fails, then the task will also fail and the platform will display the warning symbol on the VM.
To acknowledge and delete a warning symbol, click on the symbol to remove it.
If your user role is an administrator role with the privilege to "Manage Users", then you can also delete warnings for the users of the enterprises that you manage.
In the API the valid VM states are: NOT_ALLOCATED, ALLOCATED, CONFIGURED, ON, PAUSED, OFF, LOCKED and UNKNOWN. See VirtualMachineResource An additional state for protecting VMs by locking them against user actions is the MAINTENANCE state.
|The VM does not exist on the cloud node; it is just a template of the VM to be deployed and it only exists in Abiquo. The physical machine and other resources are not allocated in the cloud node and it is not consuming resources. For example, if you add a VM template to a virtual appliance with a VM that is deployed, the VM you just created is not deployed and its state is not allocated. If you undeploy a virtual appliance, then all the VMs in the virtual appliance will be undeployed, and these VMs will be in the not allocated state. |
|Allocated||The VM does not exist on the cloud node but a physical machine or provider has been assigned to it. When you deploy a VM, the first step in the deploy process is the resource scheduling or allocation. After resource allocation, the VM is in the allocated state. This state is usually a short step in the deploy process.|
|Configured||The VM exists on the cloud node. Resources such as network and volumes are allocated to it on the physical machine or in the provider. After the VM is configured in the hypervisor or provider, the VM is in the configured state. This state is usually a short step in the deploy process.|
|The final step in the deploy process is to power on the VM. A VM in the on state is exists in the cloud node and is running.|
|The VM exists on the cloud node and the VM is suspended.|
|The VM exists in the cloud node but it is not running. Resources are still allocated in the cloud node.|
An operation is being performed on the VM. The status bar shows LOCKED but it is covered by the progress notification. VMs awaiting workflow review will be locked with the progress notification "Waiting to be reviewed"
The platform does not have information about the current state of the VM but the machine exists on the cloud node. VMs may be put in the UNKNOWN state if there is an issue with a connection to the hypervisor or provider, To delete a VM in the unknown state, you need the "Delete unknown virtual machine" privilege and also access to the enterprise or the "Administer all enterprises privilege". The platform does not display VMs in the UNKNOWN state and their resources on the dashboard and it does not count them in allocation limits for CPU, RAM, and storage.
|The administrator can lock or protect a VM for maintenance when it is in any of the deployed states of on, paused, or off. See Protect a VM|
Additional VM state in Microsoft Azure
Off - Deallocated
The VM exists in Azure but it is deallocated. This means:
The deallocated state is not an Abiquo VM state, but Abiquo recognizes this state in Azure after a hard power off. A VM in the deallocated state will have the "deallocated" attribute set to "true".
|o Empty||There are no VMs in the virtual appliance|
|o Deployed||All of the VMs are not in the Undeployed state. All the VMs exist in the hypervisor or provider and none are in the Unknown or Locked state. Resources are allocated in the cloud node.|
|o Undeployed||All the VMs are in the Undeployed state. None of the VMs exist in the hypervisor or provider, and none are in the Unknown or Locked state. The virtual appliance can be seen as a template. Resources are not allocated in the cloud node.|
|o Partially deployed||This state occurs when a virtual appliance that is in the Deployed state is modified, for example, by adding a new VM. This state indicates that the configuration of the virtual appliance in the cloud node is different to the configuration of the virtual appliance in the Abiquo Server (database). To update the cloud node with the changes, click Deploy all VMs.|
One or more of the VMs is in the Locked state and none is in the Unknown state. Note: Virtual appliances awaiting workflow review will be locked with VM state Waiting to be reviewed
|o Unknown||Some or all of the VMs are in the Unknown state. The virtual appliance state is unknown when the VM states cannot be recovered from the hypervisor or provider. To continue working with this virtual appliance, the system administrator must take action.|
Some of these states are shown in the virtual appliances lists in following screenshot:
Deployed State and Powered Off Virtual Machines
The fact that all the VMs in a virtual appliance are powered off does not imply that the virtual appliance is undeployed. A deployed virtual appliance is always consuming resources because the VMs exist in the cloud nodes. An undeployed virtual appliance is not consuming resources. In Microsoft Azure a deployed VM in the "Off - deallocated" state is not consuming cloud resources
This can include actions on scaling groups, unless the administrator selects the option to disable workflow in the scaling group. To view the list of workflow tasks To filter workflow tasks, enter text in the filter box at the top of the tasks list. Screenshot: A user can cancel their own tasks To manually start a task and override the workflow control: Screenshot: A user with the privilege to Manage workflow tasks can start their own tasks
Display VM workflow tasks
Cancel VM workflow tasks
Start queued VM workflow tasks
This can include actions on scaling groups, unless the administrator selects the option to disable workflow in the scaling group.
To view the list of workflow tasks
To filter workflow tasks, enter text in the filter box at the top of the tasks list.
Screenshot: A user can cancel their own tasks
To manually start a task and override the workflow control:
Screenshot: A user with the privilege to Manage workflow tasks can start their own tasks
Success status code: 200
To manage the virtual machine using the API, first you need to retrieve the virtual machine and find the links for different actions. Remember to see VirtualMachinesResource for full details of virtual machine operations using the Abiquo API.
Send a PUT request to the VM state link
The VM state link is a link in the VM object with the "rel" attribute set to state. The "title" attribute contains the current state. You can send a PUT request of a virtualmachine state object to the link (in the "href" attribute) to change the power state of the VM.
Here are some examples of virtualmachinestate objects and notes about changing VM states
Hard power off
When you perform a power off via API, the response will include a link where you can monitor the progress of this operation. For an example of a hard power off, see https://wiki.abiquo.com/api/latest/VirtualMachinesResource.html#change-the-state-of-a-virtual-machine
To perform a graceful shutdown, your VM will need to have guest extensions installed on it. After an operation completes, you can view the status of the task by going to the link in the accepted request link of the response. In this case, the graceful shutdown was successful.
Azure power off and deallocate
Azure has two power off states - powered off and deallocated.
To power off a VM in Azure via the Abiquo API, use the graceful shutdown
To deallocate a VM in Azure via the Abiquo API, use the hard power off
The deallocated VM will have a "deallocated" attribute that is set to "true".
To reset a VM using the API, use a POST request to the reset action link. If you are using a test environment, you may wish to add the --insecure option.
Success status code: 202