The user interface of the Cloud Broker (Broker) requires a screen resolution of at least 1024 x 768 for productive work. It is based on HTML5 and you must use browsers that support these HTML5 features:
Drag and drop
The following browsers are compatible with the user interface.
Recommended Operating System
Trust the site and enable active scripting - for Abiquo login and infrastructure map.
Windows, Linux, Macintosh
Windows, Linux, Macintosh
For mobile devices, check if your browser is compatible with HTML5 using a test such as https://html5test.com/
Through the Broker you will access virtual datacenters (VDCs) that are separate groups of virtual resources. A VDC has equivalents in each cloud provider, so it gives you a common interface and API to all the providers. For example, the Broker’s concept of the VDC is equivalent to:
Within its VDCs, the Broker groups VMs into virtual appliances (VApps). The purpose of the VApp is to enable you to manage a group of VMs together, which means that you can do things such as:
You can move VMs from one VApp to another.
A VApp is not equivalent to any specific concept in vCloud or public cloud.
In vCloud, the Broker supports the onboarding of the following networks:
External networks outside the OrgVDC but connected to the Edge are external networks in the Broker, for use by load balancers but not VM vNICs
External networks outside the OrgVDC with a direct connection to OrgVDC as OrgVDCNetwork are external networks
Org networks inside the Org VDC and routed through the Edge are external networks
Isolated Org networks are external networks, for use by VM vNICs but not load balancers
vApp networks are private networks
All providers support auxiliary disks for VMs.
When you create a VM from an instance template, the platform will display one disk only, with the total size of all disks. After you deploy the VM, the platform will update the additional disks.
Your existing resources will be onboarded for you to manage with the Broker, and you can create new resources using the Broker’s web interface or the API. We recommend that you make all changes in the Broker; however, it is often possible to synchronize compatible changes made outside the Broker.
When you synchronize a VDC, the Broker will ensure that the resources in the Broker and the provider are the same.
You can also synchronize resources such as networks, public IPs, firewalls, volumes, and load balancers.
The Broker collects and displays the metrics that the provider or hypervisor sends.
Cloud providers may have resource limits, such as a limit on the number of public IPs that each account can use. As multiple users may work with the same account in the Broker, your administrator may also set limits in the Broker to ensure that the resources are correctly shared with sufficient resources available to all users. Of course, you may able to bypass the Broker’s limits by working directly in a cloud provider. However, after you onboard or synchronize resources, the Broker may block deploy, reconfigure, or undeploy actions on these resources.
The Broker identifies the VMs it creates with a UUID (universally unique identifier) and a VM Name (generally ABQ-uuid).
When the Broker onboards a virtual datacenter, it will use the following:
When the Broker creates a VM in the cloud provider, it assigns the VM Name to the VM. This is the Broker’s identifier for the VM
In Amazon, the Broker assigns the VM Name to the virtualMachine tag of the VM.
In vCloud, the Broker assigns the VM Name to the Name attribute of the VM. The Broker assigns the Abiquo UUID to the VM metadata. When you perform a "Copy to" or "Move to Catalog" action directly in vCloud, it will copy the metadata. You must remove this metadata to prevent multiple VMs with the same ID. In this situation, the plugin will disregard one of the VMs.
If you change the Broker’s identifier in the cloud provider, you will not be able to manage the VM with the Broker again.
The Broker enables you to set a Label that is a user-friendly name to identify your VMs.
In Amazon, the Broker assigns the label to the Name tag of the VM
Planned improvement: The VM Label will be added in all cloud providers. For VMs deployed in Amazon and vCloud, you will be able to change the label in the Broker when you reconfigure the VM.
The Broker onboards and synchronizes virtual datacenter names as follows:
If the Broker onboards each of the VMs in a vCloud VDC into its own virtual appliance in the Broker, then the Broker will use the VM Label as the name of the virtual appliance.
When creating a load balancer you can enter any name in the Broker but the following providers have restrictions:
The Broker enables you to make changes to deployed VMs subject to the limitations imposed by the cloud providers themselves.
To remove a tenant, first remove its VDCs and any other resources, such as firewalls, from the Broker.
Note: If a tenant does not have valid credentials in the Broker, when you delete resources, they will remain unchanged in the provider.
If you remove the VDC’s equivalent in the cloud provider’s native interface, the broker will display the resource name in light gray to indicate that the user cannot work with the resource. You should manually remove the VDC in the Broker.
We are constantly extending the platform to provide new functionality both for individual providers and the Broker itself. The sections below review platform and provider behavior, planned improvements, and known issues for each cloud provider environment.
The cloud broker is integrated with VMware vCloud Director to enable users to work with virtual resources with VDCs based on vCloud vApps.
The cloud broker can use a vCloud Director administrator account or an organization administrator account to connect to a vCloud Director virtual datacenter. Each Abiquo enterprise should have its own organization administrator account.
The cloud broker can onboard organization networks as external networks and manage IPs. Users can also manage virtual appliance networks.
The Broker onboards vApps from vCloud as VDCs where you can create VMs using templates from the vCloud template repository.
The Broker onboards and synchronizes private and external networks. The Broker does not onboard or manage static routes or NAT. Create these configurations directly in vCloud.
When you onboard a VM, the Broker creates a placeholder template. In the Apps library, this template will be marked as Unavailable because it cannot be used to create a VM. Before you undeploy the VM you MUST create an Instance template, which will clone the VM disks. Otherwise, you will not be able to recreate the VM. When you undeploy an onboarded VM, the Broker will destroy the VM and the placeholder template.
After you create an instance template of an onboarded VM, the platform will update the VM template in the Apps library to point to this template and put it in the Available state. The Broker will save a multi-disk template correctly to the vCloud registry, but it will also appear to have a single disk in the Broker. If you undeploy a VM with a saved instance template, when you deploy the VM again, the platform will use the saved instance template. Remember to check your configuration
When the platform onboards a template from vCloud, it caches the template details in the Apps library as a template, and points to the vCloud template. When you modify the template in the Broker, this sets the default configuration of VMs deployed in the Broker using the template. It does not modify the vCloud template. After you create a VM, you can change its resources by editing the VM configuration.
If you deploy a VM and then add or remove disks, when you redeploy the VM, the platform will use the template disks.
Users can modify cores per socket values in their VMs. The cores per socket must always be a divisor of the CPU.
You can onboard existing Edge firewalls from vCloud as Classic firewalls in the Broker. Do not create security groups for VMs because they are not supported in the Broker environment.
In VDCs in vCloud in the Broker, tenant private networks are isolated by default because the “vcd.parentnetwork” property is set to “none” in the platform configuration. It is possible to configure a connection to the outside world via the orgVdc Edge gateway by setting the enterprise property “vcd.parentnetwork” for a tenant to “edge-uplink”, which is the routed internal network, or to the name of another existing orgNetwork.
When you remove a virtual datacenter from vCloud and it still exists in the Broker, when synchronizing, an error is displayed that the resource no longer exists. The user can then manually delete the VDC from the broker.
In vCloud when you create an external network that can support load balancers (direct or routed, with a connection to an Edge), you must create a static IP pool with the number of IP addresses to reserve for load balancers. The Broker uses a configuration property to set the this number. If you do not create the static IP pool or there are not enough addresses in the connected network, the Broker’s onboarding process will ignore the network. The number of static IPs reserved for load balancers is also a limit on the number of load balancers that users can create in a network.
In vCloud the Broker supports the following ethernet drivers: VMXNET3, PCNET32 (in vCloud this is VLANCE), and E1000. The Broker will use the configured VMXNET3 driver when deploying or onboarding a VM with an unsupported ethernet driver.
When you create a load balancer for vCloud, you must select a “public address”, which is an address on an external network (connected to the Edge, meaning external to the OrgVDC or external routed networks). The Broker does not support the use of private subnets for load balancers in vCloud because vCloud cannot use isolated external networks or private networks when creating load balancers. The Broker enables you to change routing rules after you create them. Limitation: The Broker does not support NSX-Edge Compact or fenced vApps.
To load balance multiple protocols and ports, you can use multiple load balancers to the same IP address but each with a different port. The algorithms vCloud supports are ROUND_ROBIN, IP_HASH, LEAST_CONN, and URI. For routing rules for incoming traffic, vCloud accepts HTTP, HTTPS, and TCP. For HTTP routing rules, vCloud supports HTTP or TCP health checks. For HTTPS rules, it supports SSL or TCP. For TCP rules, it only supports TCP.
When importing templates into the platform, the private checkbox filters to display templates in the same organization, and the public checkbox filters to display templates in other organizations.
Currently specs do not support external networks, but in vCloud, when an external network is listed in the spec validation process, you can select it, then continue with the process. The platform will create the virtual appliance correctly. Remember that you will need to ensure that there are enough external IP addresses available to use in the new virtual appliance
Planned improvements for vCloud
On VMs with multiple NICs, enable the user to select NICs to add the LB
Prevent changes in NIC order on a VM (in cloud Broker only) when you synchronize networks
The cloud broker is integrated with Amazon Web Services EC2 to enable users to work in Amazon public cloud regions with VPCs.
Each Abiquo public cloud region corresponds to a single region in Amazon EC2. Each Abiquo enterprise using the Amazon public cloud region should have its own Amazon account. Abiquo will validate your Amazon credentials (Access Key ID and Secret Access Key) with Amazon. Each tenant enterprise may register one set of credentials for the enterprise's Amazon account.
Abiquo creates a Virtual Private Cloud (VPC) for each Abiquo virtual datacenter. The VPCs have NAT support with a public subnet, and VMs on different subnets can be connected to the same load balancer. Abiquo supports the AWS gateway address as the first address in the network. Users can attach Elastic IPs to VMs with a connection to the public subnet. Abiquo uses VPC networking Scenario 2 as described in the AWS documentation http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html.
When you create a VDC, the Broker configures VPC networking. Under this configuration, users must attach Elastic IPs to VMs with a connection to the public subnet. And by default, VMs in private networks will have internet access through the public subnet. Amazon uses an Elastic IP for the NAT gateway. When creating the NAT gateway of a VPC, the Broker will reuse elastic IPs that are not assigned to a VDC.
Amazon reserves five IP addresses in your private networks. It reserves the first four IP addresses and the last IP address of the VPC private connect network. These IP addresses are not displayed or used by the Broker. Therefore, the first available IP address in a network that is defined to start with address 0, will be address 5, and the gateway address will be address 1.
You cannot deploy an AMI from the AWS marketplace because the Broker cannot display the EULA for you to accept. However, you can deploy in the Amazon cloud native interface and onboard in the Broker. If you import an AMI from the AWS marketplace, the Broker will display a warning message.
If you need to manage Elastic IPs directly in Amazon, synchronize them to update the Broker with the changes or you may see unexpected results.
When onboarding a VPC, the Broker will detect a public subnet by the presence of a custom route table and NAT gateway. The Broker can also import other network configurations, such as VPCs without a NAT gateway. Users with bespoke configurations should check the results of onboarding.
The platform will onboard and synchronize private and public IP addresses even if they are not in use by VMs, and it will indicate the IP addresses in use by provider entities by displaying provider identifiers.
The Broker will import VM templates. If the VM template cannot be found, the VM will be created in the platform with no registered template. In this case, to save a copy of your VM disk as a template (so you can recreate the VM after undeploying), make a snapshot (instance) template of the VM.
Before deleting VDCs, always check which is the default VPC in your region because it may be inconvenient to delete this VPC.
Amazon load balancers are created for VDC networks (VPC subnets). The Broker will not create a load balancer in Amazon until it is assigned to at least one subnet. You can have VMs in different subnets attached to the same load balancer. For high availability, create private networks (subnets) in different availability zones in your VDC.
When you modify a load balancer in the Broker, you can add new subnets and delete subnets.
After a load balancer is created in Amazon, the provider will not allow you to change the description.
When you are creating a load balancer for Amazon, and you would like to add a firewall, if the firewall does not display, 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 create a load balancer in the Broker only, do not supply a subnet. To later create it in the provider, select a subnet. If you delete the load balancer directly in the cloud provider’s interface, it will also remain in the Broker only. You can then later assign the load balancer to another VDC. The cloud Broker never stores SSL certificates, so you cannot create a routing rule for a secure connection in a Broker-only load balancer.
A load balancer in Amazon will assign a previously unhealthy machine a healthy status after a number of successful health checks. The required number of health checks is configured for the Broker.
For Amazon load balancers, you can add a new certificate or an existing one registered in Amazon with an ARN. Remember that to list and upload SSL server certificates to IAM your Amazon user credentials will require IAM privileges to manage IAM.
Amazon only supports the ROUND_ROBIN protocol. To manage multiple incoming connections, use one load balancer with multiple incoming connections to different ports. You can only create one routing rule per protocol and path. You must create at least one routing rule and there must always be at least one routing rule in the load balancer. For incoming traffic, the routing rule protocols can be HTTP, HTTPS, or TCP, and the ports can be 80, 443, or 1024-65535 inclusive.
Amazon will only allow you to create one health check per load balancer. If you do not create a health check, Amazon will create a default TCP check to one of the ports specified in a routing rule. The health check name will be in the format "PROTOCOL:port", for example, "TCP:80".
The cloud broker is integrated with Microsoft Azure Resource Manager (ARM) compute to enable users to work with virtual resources in VDCs based on Azure virtual networks.
Each Abiquo public cloud region corresponds to a single Region in Azure. Each Abiquo enterprise using the Azure public cloud region should have its own Azure account or be a customer of an Azure reseller CSP. Each enterprise must have an Azure subscription and from there they must create an ARM application and add credentials of the application to Abiquo.
In Azure a VDC is a virtual network and its associated resources. The Broker will map a private network to a subnet in the VDC network.
For Azure, users can add public IP addresses to their VDCs and VMs, as in Amazon. Azure uses the first public IP address as the primary IP for remote access. The Broker will onboard and synchronize dynamic public IPs.
The Abiquo instance functionality was disabled in Azure in Abiquo 4.7.0 pending further development.
Azure only supports one firewall policy per VM. When you edit a firewall, Azure does not allow you to change the name, but you can modify the description, which is also stored as a tag attached to the security group.
Azure does not allow you to attach a VM with a Basic hardware profile to a load balancer. Azure does not support premium storage for some hardware profiles. The Broker does not enable you to configure VMs with premium storage.
The load balancing algorithms supported by Azure are DEFAULT, SOURCEIP, and SOURCEIPPROTOCOL. The load balancer must have one and only one public OR private address. The load balancer can only be attached to one subnet, which is mandatory for private addresses. One load balancer can have multiple incoming connections to different ports.
You must create at least one routing rule. There must always be at least one routing rule in the load balancer in the Broker. You can only create one routing rule per incoming port and one rule per outgoing port (i.e. two rules cannot receive traffic on the same port or route it to the same port). The Broker does not onboard or synchronize Azure load balancers without routing rules, because it does not support them. You can create routing rules for connections over TCP or UDP, and the IN and OUT ports of the rule must be the same.
In the Broker you can only configure one health check for an Azure load balancer, for protocols TCP or HTTP on a port between 1 and 65535. The health check interval must be between 5 and 2147483646.
The Broker enables users to filter Azure templates by publisher
When you undeploy in the Broker, it completely removes the VM and the associated resources. If you undeploy a VM in the Azure portal, you should check for orphan network interfaces because you may need to remove them before you redeploy the VM.
Limitations for Azure
The Broker does not support load balancers with SSL or firewalls (NSG)
The following reports are currently available in the Abiquo Cloud Broker Platform.
Audit and Compliance Report for Administrators
Planning Report for Administrators
This document describes how to deploy a basic web architecture in the Cloud Broker. First you should create the networks directly in vCloud and then you should configure and deploy the servers in the Broker.
In vCloud, create the following networks:
Net1: external network connected to the external interface of the Edge, as if it were a public network (Direct network) - Created by Provider during onboarding
Net2: internal network connected to the internal interface of the Edge, to protect the 2 front-end servers (FE1 and FE2) with the firewall. (Routed network) - Created by Provider during onboarding or by the customer
Net3: internal network with FE1, FE2 and 1 back-end server (BE). (Isolated network). This network is not connected to the Edge, so the connections to the VM will not be load balanced or protected by the firewall- Created by the customer
In the Broker, create a virtual datacenter
Go to Cloud → Virtual datacenters list
Click + add and select Create virtual datacenter
Enter the Name and select the Location, which is the public cloud region (vCloud Org VDC name)
Import the external networks, load balancers, and classic firewalls
Go to Cloud → select the Virtual datacenter → click the round arrow refresh button
Create the web front-end VMs
Go to Cloud → Virtual appliances → open the Virtual appliance by clicking its Name
Drag and drop or double-click two templates to create front-end servers
Edit each VM
Enter the name and other details as required
Go to Network
Drag the first IP address (NIC 0) on the routed network (net2) to add it to the VM
Add another IP address (NIC 1) on the isolated network (net3)
Create the back-end VM
Edit the VM and configure a NIC on the isolated network (net3)
Configure a load balancer in the public cloud region
Go to Virtual datacenters (Click the Back to VDC button at the top left)
Select All Virtual datacenters → Network → Load balancers → select the public cloud region
Click + and create a load balancer
Select an Automatically created private IP address. This will be an address on the external routed network - net1
Select net1 as the subnet
Create a routing rule for HTTPS-443
Create a health check with SSL
Attach the front-end servers.
Make a note of the load balancer IP address for configuring the firewall
Configure the firewalls from the public cloud region
Go to Virtual datacenters → select All → Network → Classic firewalls → select a location.
At the top of the Classic firewalls list, click the double-arrow button to onboard firewalls.
Select the firewall and click the round arrows synchronize button next to the firewall name
Create a firewall rule allowing only HTTPS-443 to the load balancer IP address from any IP address
Create a scaling group for each VM
Select the VM and from the options menu → select Define scaling group
Enter the Name and Default cooldown for example, 900 seconds for a Windows VM
Set a Minimum of 2 VMs and a Maximum of 4 VMs
Create Scaling rules for default scaling, for example, to add 1 VM and remove 1 VM
Configure the autoscaling action
Click Show more to configure the scaling thresholds
Use the default of All data points and enter 15 minutes
To enable scaling to start, click the cog icon to leave maintenance mode.
The Broker will create the scaling group, and automatically create the alarms, alerts, and action plans for autoscaling. The Broker will automatically deploy VMs to create the minimum number in each scaling group.
When any of the VMs reach the maximum CPU threshold, the Broker will automatically scale out.