This manual is a basic guide to how to Administer and Use Public Cloud in Abiquo
All users should configure their user accounts before starting work with the cloud platform.
You can control the resources that an enterprise may consume. This will help prevent resource over allocation, enterprises using resources from other enterprises, and even DoS attacks. Allocation limits will also help system administrators to anticipate user needs and forecast resource demand. Hard and soft limits are used by the resource scheduler to decide if a user can deploy a virtual appliance or not.
Enterprise allocation limits are checked during configuration or deploy, or before operations as shown in the above table.
To set the datacenters and public cloud regions that an enterprise is allowed to access, edit the Enterprise and click the Datacenters tab.
Select one or more datacenters or public cloud regions in the left pane and drag and drop them into the "Allowed Datacenters" right pane.
Access to at least one datacenter or public cloud region is required in order to deploy VMs. The left pane contains datacenters, which are "Prohibited Datacenters" by default.
Datacenters Automatically Assigned to Current Enterprise on Creation
By default, when a datacenter or public cloud region is created it is automatically assigned as Allowed for the current user's enterprise only.
Note that Allowed datacenters are working datacenters where users can deploy. This is different to an admin user having administration Scope to administer the infrastructure of datacenter.
You can set resource allocation limits for this enterprise in each allowed datacenter or public cloud region. To set allocation limits, select one of the Allowed Datacenters in the right pane and click the edit button. Set these limit values in the pop-up that opens.
If the tenant does not have cloud provider credentials, they should follow their cloud provider's instructions on how to obtain access to the provider's API.
Abiquo provides basic guides to obtaining credentials, but the tenant should always consult the cloud provider for the most up-to-date information.
Before you enter public cloud credentials, there must be an existing public cloud region for the provider.
To add credentials for a public cloud provider
In the Abiquo Apps Library you can compile a selection of certified public cloud templates for your users to deploy by self-service.
Abiquo will store the details of these templates but not their disks.
Public cloud libraries can have many thousands of VM templates (e.g. AWS has 19,000 AMIs) that are difficult to find and manage. In addition, administrators cannot control the content of public cloud templates. In the Apps library, you can define a cache of details of your approved or certified public cloud templates. And you can customize the templates' representation to make it even easier for cloud users to find the right template.
To display the details of a template, move the mouse over the template. A tooltip will display the template information.
To filter templates in the Apps library:
To reset filter values to defaults, click Clear.
This section describes tasks that will generally be performed by a tenant administrator. These tasks will vary depending on the cloud platform configuration.
To display all the virtual datacenters in specific providers, click the funnel filter button at the top of the list and select one or more providers.
In private cloud with hypervisors, the platform saves the disks and a copy of the original template definition, unless the VM was captured from outside Abiquo, in which case it saves the configuration of the VM. The platform stores the instance under the master template in the Apps library. An instance is a copy of the selected disks of a VM made at a given time and stored as a VM template. In public cloud providers, the platform saves the instance as a new VM template with disks and the configuration of the VM. Remember to enter a name that will help you to identify the instance template
In the platform, hard disks are non-persistent and they are destroyed when deleted from the VMs or when the VMs are undeployed. In private cloud datacenters with hypervisors, the platform creates hard disks on the hypervisor datastore.
In private cloud datacenters, volumes are persistent and independent of the VMs. The platform creates volumes on external storage devices. Volumes are available in private cloud datacenters with hypervisors and they require the external storage feature.
A persistent VM template has one or more persistent disks on external storage volumes. Persistent VM templates are available in private cloud datacenters with hypervisors and they require the external storage feature.
Persistent VM template disks are associated with a specific virtual datacenter. Hypervisors running persistent VMs will work directly from any persistent volumes. VM data stored on a persistent disk will be persisted on the external storage device. When you undeploy a VM, all changes made to the non-persistent disks will be lost. The next time you deploy the VM, the non-persistent template files will be freshly created, for example, standard template disks will be copied again from the appliance library to the target hypervisor. Note that it is not necessary for you to use a persistent disk as a system disk when you create a persistent VM.
Depending on their user privileges, the tenant administrator may be able to do the following tasks
If your public cloud provider does not support virtual datacenter entities, the platform will automatically onboard when you select the public cloud region.
By default, all users have access to all virtual datacenters. However, you can select a list of virtual datacenters for each user and they will only be able to access these virtual datacenters.
To restrict VDC access, open Users view and create or edit a user who is not an administrator or who does not have the No VDC restriction privilege.
On the create or edit dialog, select the Restrict access to VDC checkbox to open the list of available virtual datacenters. If none are selected, the user will have access to all VDCs. Select the VDCs where this user will be able to deploy VMs. You can only restrict the VDC access of users without the No VDC restriction privilege.
This section describes how to manage networks in private datacenters and public cloud providers.
Screenshot: Private networks in private cloud
Screenshot: Private networks in public cloud (AWS)
In the Networks list, to view the pool and allocation of IPs:
You can then:
Private networks are only available within a virtual datacenter. However, your cloud provider may configure an external gateway for your virtual datacenter.
To create a private network:
Create private network
Create private network Amazon
Name of the network (VLAN). The name can contain up to 128 characters
|IPv6||Select checkbox for IPv6 network|
Private address range of the network
|Netmask||For IPv4 a network mask with an integer value of between 16 and 30|
Gateway of the VLAN. Must be an IP within the range of the network address and mask
|Availability zone||In AWS, optionally select an Availability zone for high availability. To deploy a group of VMs separately, use a different availability zone for each VM. To assign a VM to an availability zone, assign a private IP address in the network belonging to the required availability zone|
The primary DNS
The secondary DNS
The DNS suffix
|Excluded from firewall||Select Excluded from firewall to define a network where VM firewalls will not apply|
In supported providers, optionally select Define to create static routes. See Configure Static Routes using DHCP
Select to make this network the default network, replacing the existing default network
You can configure static routes when you create or edit a network. However, you should check with your systems administrator about when your VM will receive changes to static routes.
Destination network mask
Destination network or host
Next hop (on your network)
Name of the VLAN. The name can contain up to 128 characters
|IPv6||Select checkbox for IPv6 network|
|Strict||IPv6 only. If you select Strict, Abiquo will automatically generate the network address (ULA) and also the IP addresses. If you do not select strict, you can enter the network address and IP addresses.|
|Netmask||Network mask of 48, 56 or 64.|
Private address range of the network. Only for non-strict networks
The primary DNS
The secondary DNS
The DNS suffix
Make this network the default network. In a datacenter, this will override the existing default network
To create new IP addresses in a private network do these steps.
Or you can add an IP directly to a VM. To do this:
When you add IPv6 addresses on strict networks, you don't need to set the starting address. On non-strict IPv6 networks, Abiquo recommends that you create an automatic IP address, or you can enter a From IP address manually.
The new settings will apply to all VMs deployed after you save the network.
To delete a private network:
To display onboarded external networks
If an onboarded network has been deleted in the provider, its name will display in light gray text. If a VM is using an IP from this network, then you cannot deploy the VM.
If there are no VMs using the IPs of an external network that was already deleted in the provider, to delete the network in the platform, select it and click the delete button.
To set a new or existing network as the default:
In private cloud, if you set a public network as the default, remember to obtain IP addresses for your VMs before you deploy!
To add new public IP addresses to your virtual datacenter:
The platform will add the IPs to your VDC
You can also reserve public IPs directly from the Edit VM dialog.
During onboarding from public cloud, the platform will onboard existing public IP addresses in providers that support them, such as AWS and Azure. You can obtain them from the provider and assign them to your virtual datacenters and VMs.
The provider may charge for public IP addresses as soon as you reserve them for your virtual datacenter. Therefore you should reserve your IP addresses just before you deploy and check they are deleted when you undeploy your VMs. Remember that your provider may also limit the number of public IP addresses that you can use per virtual datacenter.
To add public IP addresses to your virtual datacenter, so that you can later assign them to your VMs:
Now when you edit a VM in the VDC and go to Network → Public, the platform will display the public IP address and you can add it to your VM.
To obtain a public IP directly for a VM, click Purchase public IPs.
To onboard any public IP addresses that were already created in your cloud provider, or update changes made directly in the provider:
You can release a public IP if it is not assigned to a VM.
In private cloud, to release a public IP that belongs to a public network, select the IP in the IP list and click the delete button.
In public cloud, click the link to Remove from VDC and then click the delete button.
This section describes firewall policies, which are similar to security groups. The platform supports firewall policies in private cloud with network managers (NSX, Neutron) and in public cloud (AWS, Azure). In Oracle Cloud, the platform enables users to onboard classic firewalls and assign them to VMs.
In vCloud Director, the platform supports classic firewalls, which are Edge firewalls at level of the public cloud region (orgVDC). The platform does not support security groups for VMs in vCloud Director. See Manage Classic Firewalls
To synchronize firewalls do these steps:
To synchronize a firewall before you add new firewall rules:
The platform can create firewall policies in virtual datacenters in the provider, or in the platform only, for later use in providers, depending on provider support.
To create a new firewall, do these steps:
Name of the firewall policy.
|Location||Public cloud region or datacenter|
|Default||Optional. Select to make the firewall the default for the virtual datacenter|
Description of the firewall policy
If you entered a virtual datacenter, the platform created your firewall in the provider. The platform will display a Provider-ID and a Virtual datacenter ID for the firewall.
If you selected No virtual datacenter, the firewall will be created in the platform in the public cloud region for your enterprise. The synchronize process will not update this firewall. The platform will not create it in the provider until you select a virtual datacenter.
To set or unset a default firewall for a virtual datacenter:
When the user creates a VM, the platform will assign the default firewall. The firewall rules apply to VMs, not individual NICs on the VMs. Changes to the firewall ruleset will apply to every VM in the virtual datacenter with the default firewall. If you do not set a default firewall but the provider requires one, for example, AWS, the platform will set the provider's default firewall. In AWS the default firewall is not marked.
To edit a firewall policy:
Name of the firewall policy
|Default||Select this option to set the firewall as the default. Note: The platform will not assign the default firewall to existing VMs.|
Description of the firewall policy
If the provider does not allow you to edit the policy, you may be able to delete the firewall in the provider, then reuse the configuration.
Amazon allows you to edit firewall rules and you can do this through the platform. First synchronize the firewall to update the rules because AWS will not allow you to create a rule that already exists in the security group. Remember that it may take some time for firewall rules to propagate throughout AWS. Until the rules have propagated, the platform will not be able to detect them. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/query-api-troubleshooting.html#eventual-consistency
To edit an AWS firewall in Abiquo, you can delete the firewall directly in the provider, then synchronize so the provider ID will be removed from the firewall in the platform. You can now edit the firewall and the firewall rules, and you can even assign the firewall to another virtual datacenter. The following screenshot shows the default firewall for several different VDCs. The "webDB" firewall currently exists in AWS. The other firewalls have been created in the platform but are not assigned to a virtual datacenter and do not currently exist in AWS.
To add a new firewall rule:
To delete firewall rules, do these steps.
To display firewalls that exist in a virtual datacenter in the provider:
To display all firewalls in a location (public cloud region or datacenter), including those that only exist in the platform and not in the provider:
To filter firewalls, enter text in the Search box to search by the Name, Description, and Provider ID in the Firewalls list.
To move a firewall to another virtual datacenter:
In Neutron, edit the firewall in Abiquo and change the VDC
To assign a firewall with no virtual datacenter to a virtual datacenter, do these steps
Go to Virtual datacenters → All → Network → Firewalls
Select a cloud Location
To delete a firewall policy:
A: In the Abiquo API, the firewall object contains a link to the virtual datacenter it belongs to. In AWS or Azure ARM, if a firewall has a provider ID, then it exists in the cloud provider. The provider ID is the AWS security group ID or the Azure firewall name.
Please refer to cloud provider documentation as the definitive guide to the load balancing features. And remember to check your cloud provider pricing before you begin.
In vCloud Director, load balancers belong to a public cloud region, not a virtual datacenter. This means that in vCloud Director, you can attach VMs from more than one virtual datacenter to the same load balancer, and these load balancers do not work with private networks, which belong to only one virtual datacenter.
To display load balancers in a region, including those that are not assigned to a virtual datacenter in a provider
To display load balancers in virtual datacenters:
Select a virtual datacenter
Go to Network → Load balancers.
To create a load balancer:
Click the + add button and complete the following dialogs according to your cloud provider's documentation
The following screenshots are from AWS.
The name of the load balancer.
In providers that support subnets, the subnets to which the load balancer will connect
See cloud provider documentation for more information
Select one of the common protocols to load presets
The incoming protocol to the load balancer. See cloud provider documentation for accepted values.
The incoming port to the load balancer. See cloud provider documentation for accepted values.
The outgoing protocol from the load balancer.
|Port out||The outgoing port from the load balancer|
|SSL Cerftificate||For secure connections (e.g. HTTPS), you can add an SSL certificate.|
|Add||Click Add to save a routing rule for the load balancer|
To delete a routing rule, click the delete button beside the name of the routing rule in the list
Name of the certificate
The certificate contents
An intermediate certificate can be issued by a provider to support older browsers that may not have all of the trusted root certificates for that provider, so that users will not receive invalid SSL warnings. If you have an intermediate certificate, add it at the same time as the certificate to ensure that a trusted-chain certificate is configured.
The RSA private key for the certificate
Select one of the most common protocols to load presets
Name of the health check
The protocol with which the health check will be performed
The port to which the health check will be performed
|Path||The server path to ping (for supported protocols)|
|Interval (sec)||The interval in seconds between health checks|
|Timeout (sec)||The timeout in seconds after which an attempted health check will be considered unsuccessful|
|Attempts||The number of attempts before the health check will be considered unsuccessful|
|Add||Add the current health check to the load balancer|
If your provider supports firewalls, to add a firewall to your load balancer, select your firewall from the list of Firewalls that were created in your provider. Rackspace does not display a firewall selection list.
If a firewall is not on the list, it may not have been properly synchronized. In this case, you will need to click Cancel, synchronize firewalls and start again to create a new load balancer.
To assign your load balancer to VMs, drag and drop the VMs them from the Available Nodes list into the Attached Nodes list.
The platform will display the Status of the load balancer nodes on the Nodes tab, if status information is available from the provider.
You can also check the status using the Abiquo API.
The cloud provider determines which elements of a load balancer that you can modify. Due to different provider support for load balancer features, it may be possible to make modifications in the platform that will later be rejected by the cloud provider, triggering an error. Check your cloud provider documentation for supported modifications.
To assign a virtual machine to a load balancer, select the load balancer from the list.
To access vCloud load balancers, and provider-only load balancers
To synchronize all load balancers in a VDC or region:
Load balancers that have been deleted directly in the provider are displayed in light gray text. You can edit these load balancers to recreate them in the provider, or delete them.
If your enterprise does not have credentials in the provider, then the load balancer will be released (it will be deleted in the platform but it will remain in cloud provider).
This section describes the tasks that may be performed by the cloud user.
After you log in, you may need to edit your user account to update your details:
Add your public key that that the platform will use to launch VMs so that you can access them with SSH
Edit user general information
Edit user advanced
A virtual appliance is folder that holds a group of VMs so that you can easily access them and launch them into the cloud together. At the virtual appliance level, you may also be able to create templates from the disks of your VMs, view VM metrics and create alarms.
To create a new virtual appliance:
The platform will create the virtual appliance. To open it, click on its name.
Screenshot: Select a virtual datacenter and click Create virtual appliance
Screenshot: Create a virtual appliance
The name of the virtual appliance
The virtual datacenter where the virtual appliance will be deployed, selected in the V. Datacenters list or with this selector
|Icon||The URI of the icon to represent the virtual appliance|
|(Checkbox)||To go straight in to the virtual appliance, select Automatically open it after creation|
To create a VM:
The platform will create your VM. The status bar below the VM icon says NOT_ALLOCATED, which means that the VM has not yet been launched into the cloud. Select your VM to display its details in the lower panel.
Screenshot: Create a VM with drag and drop
Screenshot: Select a hardware profile
To launch your VMs, click the Deploy virtual appliance button on the right-hand side of the screen.
The platform will launch the VMs and power them on. The status bar below each VM icon will be coloured green. And the Deploy button changes to become the Undeploy button, which you can use to destroy the VMs.
Screenshot: Deploy a virtual appliance
To display the VM control panel, select the VM icon. From this panel, you can:
By default, the description panel provides a short description of the VM template.
The following screenshots show the Network and Storage panels, which are an easy way to check what IP addresses and storage are assigned to your machine.
To change the general configuration of a VM:
Edit virtual machine General
Continue configuring your VM or click Save to finish
If the VM is deployed but other VMs are not deployed, the changes might not be applied directly. You may need to click the Deploy all VMs button to apply the changes in the hypervisor.
Chef is an infrastructure automation product that uses configuration recipes. You can use Abiquo Chef Integration to deploy a VM that will then configure itself using Chef recipes and roles.
The Chef tab is enabled if the enterprise is Chef-enabled and the VM template is Chef-enabled. Before the VM is deployed, you can select from the available roles and recipes. These will be added to the machine's runlist. When the machine is deployed it will download the roles and recipes, and run them in order. Click the Chef tab. By default on this tab you can select roles. Mark the "Select individual components" checkbox to select individual recipes too. The selected recipes will be added to the Virtual Appliance's runlist in order of selection.
To change the order of the runlist, click on the pencil button beside a role or recipe, then edit the order number, then click OK.
To change the runlist order after deployment click on the pencil button, then edit the order number, then click OK. The Abiquo Chef Agent will connect to the Chef Server and update the runlist.
You can enable the option to fetch metrics from the public cloud region.
To enable VM monitoring and metrics,work with a VM that is powered off or undeployed:
To display metrics for a VM, on the VM icon, click the Monitoring symbol. The metrics panel will open.
To update the display of a metric, click the refresh button.
To configure the display of a metric
To view the exact metric values in a call-out box, mouse over the monitoring graph line.
To create a highlight point, click on the metric graph line.
To simultaneously view the data for more than one VM, use the virtual appliance monitoring view.
To delete a VM, move the mouse over the VM icon, and from the options menu, select Delete. You can delete a VM that is deployed. If you undeploy a VM before you delete it, the platform may request that you synchronize the virtual appliance until you delete the undeployed VM.