Hypervisor Role Deauthorization and Reauthorization

In space.vars.product_acronym, when a hypervisor role is applied, it auto configures the compute and network services on the hosts depending on the settings defined in the Cluster Blueprint.

This guide enables you to debug issues that you may run into when authorizing or deauthorizing new compute service hosts.

A) Improper clean up of state files

Files such as /opt/pf9/data/state/compute_id define the unique compute id for a hypervisor host. When the same host is re-authorised, a new compute_id can fail to create a resource provider record in the placement API.

What to do if this happens:

• Deauthorize the hypervisor role from the host cleanly.
• Decommission the host.
• Re-authorise the host.

B) Forceful decommission leaving stale compute services in database

Forceful decommission of the host using pcdctl CLI without the role check (pcdctl decommission-node -r) can leave compute service state in the databases, causing conflicts when the same host is added back with the same hostname. Note: Option -r/--skip-installed-role-check is no longer supported.

What to do if this happens:

• As a best practice, forceful decommission is not recommended. However if it was used and there are stale compute services left in the Database, delete them with:

# openstack compute service delete <uuid>

• Restart the pf9-ostackhost service:

# systemctl restart pf9-ostackhost

C) Forceful decommission leaving stale instances on the host

Forceful decommission using pcdctl without the role check (pcdctl decommission-node -r) can leave a non-empty instance list in virsh list output, causing the role removal to fail due to existing instances on the hypervisor.

What to do if this happens:

• As a best practice, forceful decommission is not recommended. However if there are stale instances left on the host, delete them using the commands below.

List all VMs:

# virsh list --all

Destroy and undefine those VMs (use the ID from the previous command):

# virsh destroy <id>
# virsh undefine <id>

• Restart the pf9-ostackhost service:

# systemctl restart pf9-ostackhost

Host Authorization And Deauthorization Guidelines

1

Option 1 — Host has only hypervisor role

Suggested process to de-auth/auth:

• Deauthorize the hypervisor role from the host using the space.vars.product_name console cleanly.
• Decommission the host using pcdctl decommission-node (DO NOT use the -r option to skip role checks).
• Onboard the host using the instructions in the UI to add a new host.
• Re-authorise the host with the hypervisor role using the space.vars.product_name console.

2

Option 2 — Host has multiple roles and you want to retain other roles

Suggested process to de-auth/auth while retaining existing host configuration and other roles (Image Library, Persistent Storage, etc.):

• Deauthorize the hypervisor role from the host using the space.vars.product_name console cleanly.
• Re-authorise the host with the hypervisor role using the space.vars.product_name console.

Forceful decommission using pcdctl decommission-node -r is not recommended because it can leave stale state (compute services or instances) that cause conflicts when re-adding the host.