Abiquo 4.0 features

These pages describe new features and changes in Abiquo 4.0.

Horizontal autoscaling of virtual machines

Abiquo 4.0 introduces horizontal scaling of VMs to enable users to configure an automatic response to changing demands for resources. To scale out, the platform clones the base VM and deploys the clones. To scale in, Abiquo will delete clone machines but it will just undeploy the base machine. Scaling operations are subject to all standard Abiquo constraints, such as privileges and allocation limits.

Azure ARM firewall policies and load balancer policies added to the Microsoft Azure ARM integration

Firewalls: For supported features, see Azure ARM features table. For details of how to use Azure firewalls, see Manage firewalls

Load balancers: For supported features, see Azure load balancers table. For details of how to use Azure load balancers, see Manage load balancers

Abiquo AWS integration networking changes

In the AWS integration, Abiquo 4.0 creates VPCs with a different network configuration, providing NAT support with a public subnet, and also allowing VMs on different subnets to be connected to the same load balancer. Abiquo now supports the AWS gateway address as the first address in the network. Abiquo now configures VPC networking Scenario 2 as described in the AWS documentation http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html.

Control NICs in restricted networks

Abiquo 4.0 introduces the privileges to Attach NICs in restricted networks to VMs and Detach NICS in restricted networks from VMs

Hardware profiles in private cloud

Abiquo 4.0 presents hardware profiles for private cloud and public clouds without native hardware profiles.  Administrators can create and fully manage hardware profiles and their families and types in the platform. Some cloud providers may support both hardware profiles, and CPU and RAM, for example, vCloud Director.

User scopes and scope hierarchies

Abiquo 4.0 introduces user scopes and scope hierarchies. In Abiquo 4.0, administrators assign scopes to users, instead of to roles as in previous versions. During the upgrade, Abiquo will assign role scopes to users with that role. In previous versions, the default scope for all roles was the global scope. Now there is a default scope for each enterprise tenant. Abiquo 4.0 also introduces scope hierarchies for resource sharing. A scope hierarchy is for sharing resources with related tenants without the need for the administrator to have all of these related tenants in their own scope. So administrators can share VM templates and VApp specs with tenants in child scopes beneath their own scope, but administrators manage only the tenants within their own scope.

In Abiquo v4.0 the users who can administer shared resources have changed. The criteria are as follows:

• User enterprise is listed in the resource scope

• Feature privileges (e.g. Manage VM templates in the Apps library)

• Allow user to switch enterprise privilege (effectively manage shared resources)

• Full datacenter access (User Datacenter scope)

• Logged in to the owner enterprise

Abiquo backup improvements

See https://abiquo.atlassian.net/wiki/spaces/doc/pages/311368219

Guest setup in Abiquo 4.0.2

See Release notes and https://abiquo.atlassian.net/wiki/spaces/doc/pages/311372846

User interface changes in Abiquo 4.0

Changes to the documentation wiki in Abiquo 4.0

The Abiquo wiki will now always have the same URL for the current version of Abiquo. This URL will be http://wiki.abiquo.com/display/doc. When a new major or minor version is released, we will create a new wiki for the previous version of Abiquo. The URL for the previous versions will be in the format  http://wiki.abiquo.com/display/ABIXXX  where XXX is the version number, for example, http://wiki.abiquo.com/displayABI310

Changes to the Chef integration in v4.0.2

In private cloud Abiquo now uses Cloud-init to launch the Chef bootstrap process. Abiquo requires Cloud-init version 0.7.9 or later.

Chef templates:

• Checkbox to mark templates as Chef-enabled has been deprecated

• The Chef symbol is no longer used

• In private cloud, use templates with cloud-init and set Guest setup to cloud-init

• In public cloud, you do not have to set the Guest setup for templates. Use templates compatible with the provider's user data (AWS and Packet) or SSH 

Chef agent is no longer used. Bootstrap data media type is deprecated.

Allocation rules for storage

Abiquo 4.0.2 introduces storage load level rules to configure storage allocation based on datastore load. The scheduler uses these rules to decide if the datastore (and its physical machine) is a candidate to hold a VM. You can set storage load level rules with values from 0 to 100%. You can create rules for a datacenter (all datastore tiers), a tier (all datastores in a tier) or a specific datastore.

If more than one rule applies to a datastore, the most specific rule takes precedence over more general rules. For example, if there is a datacenter rule, a tier rule, and a datastore rule that all apply to the same datastore, Abiquo will use the datastore rule because it is the most specific.

See https://abiquo.atlassian.net/wiki/spaces/doc/pages/311370944

Excluded networks in 4.0.4

Abiquo 4.0.4 introduces excluded networks in private cloud datacenters. To prevent users from creating private networks that use a certain network address range, you can reserve the range by creating an excluded network. See https://abiquo.atlassian.net/wiki/spaces/doc/pages/311375688.