Host groups

Edit online

With host groups, also called host aggregates in OpenStack, you can create virtual boundaries around a group of hosts. This lets you logically partition your hosts.

Overview
What host groups are used for
Example virtual machine lifecycles

Overview

Host groups allow you to logically group hosts regardless of any features that they might or might not have in common. For example, the hosts do not have to have the same architecture, network configuration, or storage. Host groups have these important features:

Every host must be in a host group

Any hosts that do not belong to a user-defined host group are members of the default host group. The default host group cannot be deleted.

Virtual machines are kept within the host group

A virtual machine can be deployed to a specific host or to a host group. After deployment, if that virtual machine is migrated, it must always be migrated within the host group. Additionally, virtual machines that are recovered by using an untargeted remote restart must stay within the host group. However, you can use a targeted remote restart to recover a virtual machine onto a host that is not a member of the host group.

Placement policies are associated with host groups

Every host within a host group is subject to the host group's placement policy. The default placement policy is striping.

Nova availability zone support for host groups

Similar to host groups, availability zones are another way to create logical groupings of hosts. When a host group is created through the user interface, an availability zone with the same name is created and assigned to the host group. PowerVC also supports the standard OpenStack APIs for host groups and availability zones.

Notes:

The availability zone name must be unique across PowerVC and can be mapped to one host group only.
While creating a host group from the REST API, admin users can choose a unique name for the availability zone.
When a host group is created from the user interface, an availability zone is created with the host group's name. It is not recommended to update the availability zone name because it might result in any unexpected behavior of the host group on user interface.
During an upgrade, PowerVC creates the availability zone for existing host groups with the respective host group's name.

For more information, see Availability Zones.

What host groups are used for

An enterprise can benefit in many ways from using host groups:

Logically separate groups of hosts based on business need: You might create separate host groups for test, development, and production, for example.
Employ multiple placement policies: Because each host group uses its own placement policy, such as striping or packing, each host group can be assigned the appropriate placement policy, depending on the workload.
Realize Infrastructure as a Service (IaaS) Service Level Agreements (SLAs): For example, one host group might use high-end storage while a different host group uses commodity storage.

Example virtual machine lifecycles

The following examples assume this environment:

This image shows the setup that is described in the previous paragraphs.

Deploy and migrate virtual machine 1 (vm1):

Deploy vm1: You specify host group B when deploying vm1 and PowerVC uses the striping policy to put it on a host in group B.
Migrate vm1: If you then migrate vm1, it is placed on a different host in group B, according to the striping policy. You cannot migrate vm1 to a host in group A. To migrate vm1 to a host in host group A, move the host into group A before migration.
Recover vm1: If you use remote restart to recover vm1 and do not specify a host, it is placed on a different host in group B, according to the striping policy.
If you use remote restart to recover vm1 and specify a specific host, it is placed there regardless of its host group membership.

Targeted deploy of virtual machine 2 (vm2)

If you deploy vm2 to host 1, it is placed on host 1 (assuming that the host has sufficient resources) and the packing placement policy is ignored.