Administer and Troubleshoot VMs
Protect a VM
An administrator can block actions on a VM in the platform by other users who do not have the Protect virtual machine privilege.
You can lock or protect a deployed VM when it is powered on, paused, or powered off.
Privilege: Protect virtual machine
To protect a VM
- Select the VM and click the padlock protect VM button near the Deploy VM button
- In the Protect virtual machine dialog, enter the reason for protecting the 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
Restrict virtual appliances and VMs
Restricted virtual appliances and their contents are effectively not visible and/or operable by users without the appropriate privileges. This feature could be used for cases such as outsourcing virtual appliances or running provider applications in the user’s VDC.
Privileges: Manage restricted VApps and VMs, View restricted VApps and VMs, Restrict VM
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:
- Click the VM move button on the VM control panel
- To move a VM to a restricted virtual appliance, the user can do one of the following depending on their privileges:
- Select the option to Move the VM to a restricted VApp
- Select a restricted VApp from the list
- Create a new restricted VApp.
Relocate a deployed VM to another host
The relocate VM feature enables you to move a deployed VM to another hypervisor on the same rack with the same manager. This feature is available for VMware ESXi and uses the vMotion feature. This feature requires the "Relocate a VM into a compatible host" privilege. The Relocate VM button is on the VM control panel.
Privilege: Relocate a VM into a compatible host
To relocate a VM:
- Go to Virtual datacenters → open a virtual appliance → go to Virtual machines → select a VM
- On the VM control panel on the lower right-hand side of the screen, click the Relocate VM button
- The platform will display a dialog with a list of hypervisor hosts where you can relocate the VM
- Click the Show details link to display the host metrics and the Relocate button
- Select the host with the same manager where you wish to relocate the VM, go to the host section and click Relocate. The platform will display the VM status as Relocating
- After relocation, the new hypervisor location will display in the control panel, for example, with a new Remote access address. If you click the Relocate button again, you should see a different host list, including the original host.
Screenshot: Select the VM and click relocate
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.
Deploy errors
When an error occurs during a VM deploy, the platform displays one or more of the following:
- A yellow warning or red error notification message
- An error state on the VM icon
- A VM warning symbol in the lower part of the VM icon.
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.
Source: Abiquo / admin /
Date/time: 2014-4-29 13:41:41
Action: VIRTUAL_MACHINE_DEPLOY
Performed by: admin
User: admin
Trace: There are 1 candidate machines but all are oversubscribed by the current workload rules (RAM and CPU oversubscription or no suitable datastore with enough free space). Please check the workload rules or the physical machine resources. Virtual machine requires 1 CPU -- 128 RAM Candidate machines : BCN_KVM_02 ip - 10.60.13.20 .
Severity: ERROR
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.
States of VApps and VMs
It is important that administrators clearly understand the different states that virtual appliances and VMs can have in the Abiquo platform and the differences between them. In order to change the state of VMs, users will require the Perform virtual machine actions privilege.
Privilege: Perform virtual machine actions
API Feature
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.
Virtual Machine States
State | Description |
---|---|
Not Allocated | 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. |
On | 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. |
Paused | The VM exists on the cloud node and the VM is suspended. |
Off | The VM exists in the cloud node but it is not running. Resources are still allocated in the cloud node. |
Locked | 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" |
Unknown | 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. |
Maintenance | 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
State | Description |
---|---|
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". |
Virtual Appliance States
The virtual appliance states are calculated from the VM states as described below. The state name in the table has the color code for the Virtual appliance in each state.
State | Description |
---|---|
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. |
o Locked | 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
Manage workflow tasks
Display VM workflow tasks
When workflow is enabled, the user's requests to deploy, reconfigure and undeploy VMs will be held with the status waiting to be reviewed.
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
- Go to Virtual datacenters → Workflow tasks.
To filter workflow tasks, enter text in the filter box at the top of the tasks list.
Cancel VM workflow tasks
To cancel workflow tasks:
- Go to Virtual datacenters → Workflow tasks
- If you are an administrator, to refresh the list with all queued tasks for an enterprise, select a Cloud tenant from the Enterprises pull-down list
- To cancel a queued task, click the Reject link next to the task.
Screenshot: A user can cancel their own tasks
Start queued VM workflow tasks
Queued tasks are waiting for workflow control. If there is a problem with the workflow connector integration or tool, users with the privilege to Manage workflow tasks can manually continue the tasks.
To manually start a task and override the workflow control:
- Go to Virtual datacenters → Workflow tasks.
- If you are an administrator, to refresh the list with all queued tasks for an enterprise, select a cloud tenant from the list of enterprises.
- To start a task, click the Approve link beside the task
Screenshot: A user with the privilege to Manage workflow tasks can start their own tasks
Retrieve a VM using the API
This section describes how to retrieve a virtual machine with the REST API.
- Before you begin, create a VM with the Abiquo UI and power it off. Open the browser console. This example uses Chrome, so we clicked F12.
- Select the Network view
- Click the red arrow record button and the clear button next to it
- In the platform on the VM control panel, click the Start button
- Scroll up to the first request, which should be a PUT request to the virtual machine state URL. Click on the request
- If you can't see the Method column, right click on a column heading and select Method from the list
- If you can't see the Method column, right click on a column heading and select Method from the list
- Select the link to the VM up to the end of the VM ID number (before "/state")
- Use a cURL request similar to the one the example below or a REST API tool such as Postman to perform a GET request to this link. For this basic testing, you can use the -k option to avoid security warnings.
curl -X GET https://mjsabiquo.bcn.abiquo.com/api/cloud/virtualdatacenters/2/virtualappliances/1/virtualmachines/47 \ -H 'Accept:application/vnd.abiquo.virtualmachine+json;version=5.0' \ -u admin:xabiquo -k --verbose
Manage VM power states using the API
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.
To perform a power action (except for reset) on a VM using the API:
- Perform a GET request to obtain the VM object and find the VM state link
- Create a virtualmachinestate object
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.
{ "title": "ON", "rel": "state", "type": "application/vnd.abiquo.virtualmachinestate+json", "href": "https://nardo40.bcn.abiquo.com:443/api/cloud/virtualdatacenters/2486/virtualappliances/2990/virtualmachines/19454/state" },
Here are some examples of virtualmachinestate objects and notes about changing VM states
Hard power off
{"state": "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
Graceful shutdown
{"state": "OFF", "gracefulShutdown": true}
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.
Power on
{"state": "ON"}
Pause
{"state": "PAUSED"}
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.
Related pages
Copyright © 2006-2022, Abiquo Holdings SL. All rights reserved