Abiquo and Google Cloud Platform

Abiquo 5.2 offers improved support for Google Cloud Platform with a new integration that extends and improves the basic GCE integration of previous versions.

Abiquo 5.2.1 introduces VM startup scripts with cloud-init and VM monitoring for Google Cloud Platform.

For the latest details of the integration, see https://abiquo.atlassian.net/wiki/spaces/doc/pages/311378206.

Billing dashboard

In addition to all of the usage statistics, Abiquo can display the Google Cloud Platform billing data in the Home view on the Hybrid dashboard.
See https://abiquo.atlassian.net/wiki/spaces/doc/pages/311369857

Open

Billing dashboard for GCP

Public cloud regions

Creating an Abiquo public cloud region for the Google Cloud Platform is the same process as for other providers in the multi-cloud platform.

Open

Create a public cloud region in GCP

When you create a region and add credentials to an enterprise, the platform will onboard the hardware profiles. See https://abiquo.atlassian.net/wiki/spaces/doc/pages/311371154 for more details.

Hardware profiles

Google has its own families and types, which are not the same as for other providers.
If you don't have the other providers, you may see some gaps in the families and types.
Users will be able to select from lists containing the available families and types.

VM template catalog

After you create a public cloud region, you can go the Catalogue and onboard VM templates for your users.

The dialog to search for templates has a Publishers section, with a similar look to Azure.
This is a list of public projects that provide the templates. See  . 

These projects present the latest version of the templates. You can configure the default projects with Abiquo properties.

Global networks

In the Google Cloud Platform integration there are two types of networks: global networks and subnets. Global networks are private networks that span different regions. So each global network may be available in different cloud locations. When you onboard or synchronize a region, the platform will update all global networks and all the subnets from the synchronized region.

To view and manage the global networks in the virtual datacenters cloud view, click on the globe Global section symbol. 

From the Global section, you can onboard or synchronize the Global networks in a selected region, and their subnets.

The user can create a global network with options for routing and for automatically creating subnets in all regions, which is convenient for test environments.

If you create a subnet for each region, you will need to onboard the subnets. To do this, select the global network and click the round arrow synchronize button. Then select the region for your virtual datacenter.

Subnets

To enable your users to work with private subnet IP addresses, which are essential for deploying VMs in Google Cloud Platform, create subnets of your global networks and assign them to your virtual datacenters.

You can create subnets of global networks in Virtual datacenters view, Locations view, and Global view.   

To create a subnet, you will need a to select a global network. When you create a subnet, you should also select a virtual datacenter, if one is available. You can also set a subnet as the default network to automatically create IPs if the user does not create a network configuration. 

If you didn't create a virtual datacenter earlier, when you create one, you can select a default subnet. Or you can edit a subnet to assign it to the virtual datacenter.

Virtual datacenters

The Google Cloud Platform does not have a virtual datacenter entity. To onboard the virtual resources from a Google Cloud Platform region, in Virtual datacenters view, click the + add button and select Synchronize public cloud. Then select the region. The platform will create a generic virtual datacenter to manage these resources.

Virtual datacenters do not have a corresponding entity in the Google Cloud Platform, so you can only synchronize regions, with the same option to Synchronize public cloud in Virtual datacenters view. 

To create virtual datacenters for Google Cloud Platform, the process is the same as in other providers.

And we recommend that you go to the Defaults tab and assign a default Subnet when you create the virtual datacenter. This will ensure that your users can always deploy a VM, even if they do not add an IP address to the VM. This is because Abiquo needs a default subnet to automatically create a subnet IP with no user action.

The platform will create the virtual datacenter in the platform only. 

IP addresses

When a subnet is assigned to a VDC, users can select the subnet to create IPs to add to their VMs.

When users create IPs in a subnet, they can select the static or ephemeral IP type. Ephemeral IPs do not have a provider ID in Abiquo but they exist in the provider when they are attached to a deployed VM. For more details, see:  . The static IP addresses in subnets have a name and a provider ID.

The public IPs available in the Google Cloud Platform integration are static external IPs and ephemeral external IPs. When users create a public IP with Abiquo's Google Cloud Platform integration, it is a static external IP. Abiquo can onboard ephemeral external IPs as ephemeral public IPs. When the user undeploys a VM, the provider will delete the ephemeral public IP addresses.

Firewalls

The initial version of the integration with Google Cloud Platform does not allow users to onboard or manage firewall policies.

When the user onboards, synchronizes, or creates a global network, the platform will check if there is a firewall rule with the name "abq-fw-ssh-rdp-" + the SHA1 encryption of the global network name. If the rule does not exist, the platform will create it to allow SSH and RDP traffic (ports 22 and 3389)

Volumes

Users can also create volumes of external storage in Google Cloud Platform. Volumes are zonal persistent disks. For more details, see  . 

When users create a volume, they must select the Availability zone for the volume, which must be the same one as for the VM where they will use the volume. Users can then edit their VMs and go to the Storage tab to drag volumes into the VM configuration.

The platform will delete the boot disk when you undeploy the VM, because it defines it as a hard disk. But the platform will keep the other disks as volumes in the virtual datacenter. Users can add these volumes to other VMs and move the volumes to other virtual datacenters in the same public cloud region.

When you onboard resources, if persistent disks are attached to a VM, the platform will add them to the VDC and VM. Otherwise, it will add them to the cloud location.

If the user has set a flag in Google Cloud Platform to destroy the disk when they destroy the VM, Google Cloud Platform will delete the disk when the user undeploys the VM.  The platform will remove this deleted disk during the periodic check or when you synchronize the provider.

Virtual machines

When users create a VM, they need to select a template and then an Availability zone.

And then they must select a hardware profile as in other public cloud providers.

Users can drag IPs into their VM configuration, and they can add new IP addresses, including automatically generated ones. Remember that to deploy a VM, you must add a subnet IP.

When users configure VMs, to add volumes, they can drag the volumes into the Storage pane.

Startup scripts

Users can add cloud-init scripts on the Bootstrap tab. Users can use VM variables in their bootstrap scripts.

Monitoring

On the Monitoring tab, users can select metrics to display for their VMs. See VM monitoring and metrics. By default, Abiquo will get metrics from Google Cloud Platform every 5 minutes.

Remote access

After you deploy a Linux VM, you can access it via SSH with the username from the VM template and the SSH private key. The platform creates the VM with the SSH public key from the user's account.

For Windows VMs, remote access is via RDP with the template username and the template password. The platform creates the login for Windows VMs using startup scripts. You can configure the wait for startup scripts with Abiquo properties.

VM duplicate names and onboarding 

There is a limitation in the current version of the integration with VM names. VMs are created in the provider with the VM name (ABQ_uuid) and they have a label with user's friendly name. But when you onboard a VM, the platform identifies it by the name. So you cannot onboard a VM from a Google Cloud region if there is already another VM in the platform with the same name, even if it is in a different tenant. This will change soon when Abiquo introduces the change to identify the VM using the provider ID.