Configuring Virtual Machine Subscriptions in Red Hat Satellite
Using virt-who to manage host-based subscriptions
Abstract
Providing Feedback on Red Hat Documentation
We appreciate your feedback on our documentation. Let us know how we can improve it.
Use the Create Issue form in Red Hat Jira to provide your feedback. The Jira issue is created in the Red Hat Satellite Jira project, where you can track its progress.
Prerequisites
- Ensure you have registered a Red Hat account.
Procedure
- Click the following link: Create Issue. If Jira displays a login error, log in and proceed after you are redirected to the form.
- Complete the Summary and Description fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form.
- Click Create.
Chapter 1. Introduction
You can use host-based subscriptions for Red Hat Enterprise Linux virtual machines in the following virtualization platforms:
- Red Hat Virtualization
- Red Hat Enterprise Linux Virtualization (KVM)
- Red Hat OpenStack Platform
- VMware vSphere
- Microsoft Hyper-V
- Nutanix AHV
Note that the subscription model is deprecated and will be removed in a future release. It is recommended to use Simple Content Access as a substitute.
1.1. Host-based Subscriptions
Virtual machines can use host-based subscriptions instead of consuming entitlements from physical subscriptions. A host-based subscription is attached to a hypervisor and entitles it to provide subscriptions to its virtual machines. Many host-based subscriptions provide entitlements for unlimited virtual machines.
To allow virtual machines to inherit subscriptions from their hypervisors, you must install and configure virt-who. Virt-who queries the virtualization platform and reports hypervisor and virtual machine information to Red Hat Satellite.
When a virtual machine is registered with an activation key that has no subscriptions attached and auto-attach set to true
, and sufficient host-based subscriptions are available, one of the following behaviors occurs:
- If the virtual machine has been reported by virt-who and a host-based subscription is attached to the hypervisor, the virtual machine inherits a subscription from the hypervisor.
- If the virtual machine has been reported by virt-who, and the hypervisor is registered to Satellite but does not have a host-based subscription attached, a host-based subscription is attached to the hypervisor and inherited by the virtual machine.
- If the virtual machine, or its hypervisor, has not been reported by virt-who, Satellite grants the virtual machine a temporary subscription, valid for up to seven days. After virt-who reports updated information, Satellite can determine which hypervisor the virtual machine is running on and attach a permanent subscription to the virtual machine.
If auto-attach is enabled, but virt-who is not running or there are no host-based subscriptions available, Satellite attaches physical subscriptions to the virtual machines instead, which might consume more entitlements than intended.
If auto-attach is not enabled, virtual machines cannot use host-based subscriptions.
To see if a subscription requires virt-who, in the Satellite web UI, navigate to Content > Subscriptions. If there is a tick in the Requires Virt-Who column, you must configure virt-who to use that subscription.
Virtual machine subscription process
This diagram shows the subscription workflow when a virtual machine has not yet been reported by virt-who:
Satellite provisions a virtual machine.
The virtual machine requests a subscription from Satellite Server.
Satellite Server grants the virtual machine a temporary subscription, valid for a maximum of seven days, while it determines which hypervisor the virtual machine belongs to.
Virt-who connects to the hypervisor or virtualization manager and requests information about its virtual machines.
The hypervisor or virtualization manager returns a list of its virtual machines to virt-who, including each UUID.
Virt-who reports the list of virtual machines and their hypervisors to Satellite Server.
Satellite Server attaches a permanent subscription to the virtual machine, if sufficient entitlements are available.
Additional resources
For more information about the Red Hat subscription model, see Introduction to Red Hat Subscription Management Workflows.
1.2. Configuration Overview
To allow virtual machines to inherit subscriptions from their hypervisors, complete the following steps:
Prerequisites
- Import a Subscription Manifest that includes a host-based subscription into Satellite Server. For more information, see Importing a Red Hat Subscription Manifest into Satellite Server in Managing Content.
- Ensure you have sufficient entitlements for the host-based subscription to cover all of the hypervisors you plan to use.
- If you are using Microsoft Hyper-V, enable remote management on the hypervisors.
- If you are using Nutanix AHV, consult How to configure virt-who for Nutanix AHV to work with RHSM in the Red Hat Knowledgebase.
Create a user with read-only access and a non-expiring password on each hypervisor or virtualization manager. Virt-who uses this account to retrieve the list of virtual machines to report to Satellite Server.
- For Red Hat products and Microsoft Hyper-V, create a virt-who user on each hypervisor that runs Red Hat Enterprise Linux virtual machines.
- For VMware vSphere, create a virt-who user on the vCenter Server. The virt-who user requires at least read-only access to all objects in the vCenter Data Center.
Procedure Overview
- Section 1.3, “Virt-who Configuration for Each Virtualization Platform”. Use the table in this section to plan how to configure and deploy virt-who for your virtualization platform.
- Chapter 2, Creating an Activation Key for Virtual Machines. Create an activation key with auto-attach enabled and no subscriptions attached.
- Chapter 3, Attaching a Host-based Subscription to Hypervisors. Attach a host-based subscription to all of the hypervisors you plan to use.
- Chapter 4, Creating a virt-who Configuration. Create a virt-who configuration for each hypervisor or virtualization manager.
- Chapter 5, Deploying a virt-who Configuration. Deploy the virt-who configurations using the scripts generated by Satellite.
- Chapter 6, Registering Virtual Machines to use a Host-based Subscription. Register the virtual machines using the auto-attach activation key.
1.3. Virt-who Configuration for Each Virtualization Platform
Virt-who is configured using files that specify details such as the virtualization type and the hypervisor or virtualization manager to query. The supported configuration is different for each virtualization platform.
Typical virt-who configuration file
This example shows a typical virt-who configuration file created using the Satellite web UI or Hammer CLI:
[virt-who-config-1] type=libvirt hypervisor_id=hostname owner=Default_Organization env=Library server=hypervisor1.example.com username=virt_who_user encrypted_password=$cr_password rhsm_hostname=satellite.example.com rhsm_username=virt_who_reporter_1 rhsm_encrypted_password=$user_password rhsm_prefix=/rhsm
The type
and server
values depend on the virtualization platform. The following table provides more detail.
The username
refers to a read-only user on the hypervisor or virtualization manager, which you must create before configuring virt-who. The rhsm-username
refers to an automatically generated user that only has permissions for virt-who reporting to Satellite Server.
Required configuration for each virtualization platform
Use this table to plan your virt-who configuration:
Supported virtualization platform | Type specified in the configuration file | Server specified in the configuration file | Server where the configuration file is deployed |
---|---|---|---|
Red Hat Virtualization RHEL Virtualization (KVM) Red Hat OpenStack Platform | libvirt | Hypervisor (one file for each hypervisor) | Each hypervisor |
VMware vSphere | esx | vCenter Server | Satellite Server, Capsule Server, or a dedicated RHEL server |
Microsoft Hyper-V | hyperv | Hyper-V hypervisor (one file for each hypervisor) | Satellite Server, Capsule Server, or a dedicated RHEL server |
Example virt-who configuration files
Example virt-who configuration files for several common hypervisor types are shown.
Example OpenStack virt-who configuration
[root@compute-node]# cat /etc/virt-who.d/virt-who-config-1.conf This configuration file is managed via the virt-who configure plugin manual edits will be deleted. [virt-who-config-1] type=libvirt hypervisor_id=hostname owner=ORG env=Library server=qemu:///system <==== username=virt-who-user encrypted_password=xxxxxxxxxxx rhsm_hostname=satellite.example.com rhsm_username=virt_who_reporter_1 rhsm_encrypted_password=yyyyyyyyyyy rhsm_prefix=/rhsm
Example KVM virt-who configuration
type=libvirt hypervisor_id=hostname owner=gss env=Library server=qemu+ssh://root@libvirt.example.com/system username=root encrypted_password=33di3ksskd rhsm_hostname=satellite.example.com rhsm_username=virt_who_reporter_2 rhsm_encrypted_password=23233dj3j3k rhsm_prefix=/rhsm
Example VMware virt-who configuration
type=esx hypervisor_id=hostname owner=gss env=Library server=vcenter.example.com username=username_vcenter@example.com encrypted_password=33di3ksskd rhsm_hostname=satellite.example.com rhsm_username=virt_who_reporter_2 rhsm_encrypted_password=23233dj3j3k rhsm_prefix=/rhsm
The rhevm
and xen
hypervisor types are not supported.
The kubevirt
hypervisor type is provided as a Technology Preview only.
Chapter 2. Creating an Activation Key for Virtual Machines
Use this procedure to create an activation key with auto-attach enabled and no subscriptions attached. When you register virtual machines using this activation key, the virtual machines inherit a subscription from their hypervisor if that hypervisor has a host-based subscription attached.
This procedure is only valid if you have Simple Content Access (SCA) disabled on Satellite. You are not required to attach subscriptions to Activation Keys if you have SCA enabled. Note that SCA is enabled by default for newly created organizations. To learn more about SCA, see Simple Content Access.
For more information about activation keys, see Managing Activation Keys in Managing Content.
Procedure
- In the Satellite web UI, navigate to Content > Activation keys and click Create Activation Key.
- In the Name field, enter the name of the activation key.
- Ensure the Unlimited Hosts check box is selected. Alternatively, if you want to set a limit, clear the Unlimited hosts check box, and in the Limit field, enter the maximum number of virtual machines you can register with the activation key.
- In the Description field, enter a description for the activation key.
- From the Environment list, select the environment to use.
- From the Content View list, select a Content View to use.
- Click Save.
- When the new activation key appears in the Activation Keys window, click the name of the key.
- Click the Subscriptions tab.
Ensure that Auto-Attach is set to Yes. If it is not, click the edit icon, select the check box, and click Save.
Do not add any subscriptions to this activation key.
For CLI Users
Create the activation key:
# hammer activation-key create \ --name "VM_Activation_Key" \ --unlimited-hosts \ --description "For VMs to inherit a VDC Subscription" \ --lifecycle-environment "Environment_Name" \ --content-view "CV_Name" \ --organization "My_Organization"
Enable auto-attach on the activation key:
# hammer activation-key update --name "VM_Activation_Key" \ --organization "My_Organization" --auto-attach true
Chapter 3. Attaching a Host-based Subscription to Hypervisors
Use this procedure to attach a host-based subscription, such as Red Hat Enterprise Linux for Virtual Datacenters
, to hypervisors that are already registered to Red Hat Satellite.
This procedure is only valid if you have Simple Content Access (SCA) disabled on Satellite. You are not required to manually attach the subscriptions if you have SCA enabled. Note that SCA is enabled by default for newly created organizations. To learn more about SCA, see Simple Content Access.
To register a new hypervisor, ensure your host activation key includes a host-based subscription, then see Registering Hosts to Satellite in Managing Hosts. You must register a hypervisor before configuring virt-who to query it.
Prerequisites
- Import a Subscription Manifest that includes a host-based subscription into Satellite Server.
- Ensure you have sufficient entitlements for the host-based subscription to cover all of the hypervisors you plan to use.
Procedure
- In the Satellite web UI, navigate to Hosts > Content Hosts.
- In the Content Hosts list, select the check box next to the name of each hypervisor you want to attach the subscription to.
- From the Select Action list, select Manage Subscriptions.
- In the Content Host Bulk Subscriptions window, select a host-based subscription, then click Add Selected.
For CLI Users
On Satellite Server, list the available subscriptions to find the host-based subscription’s ID:
# hammer subscription list \ --organization-id organization_id
Attach the host-based subscription to a hypervisor:
# hammer host subscription attach \ --host host_name \ --subscription-id subscription_id
Repeat these steps for each hypervisor you plan to use.
Chapter 4. Creating a virt-who Configuration
Use this procedure to create a virt-who configuration. Red Hat products and Microsoft Hyper-V require one configuration for each hypervisor that runs Red Hat Enterprise Linux virtual machines. VMware vSphere requires one configuration for each vCenter Server.
Most values in this procedure are added to an /etc/virt-who.d/conf_name.conf
file and apply only to the specified hypervisor or virtualization manager. Interval, Enable debugging output, HTTP Proxy, and Ignore Proxy are global values stored in the /etc/sysconfig/virt-who
file. Global configuration values apply to all virt-who configurations on the same server, and are overwritten each time a new virt-who configuration is deployed on that server.
Every virt-who configuration creates a virt_who_reporter_[id]
user and assigns it the Virt-who Reporter
role, which provides minimal permissions for virt-who reporting to Satellite Server. This user cannot be manually configured or used to log in to Satellite Server.
Prerequisites
- If you are creating a virt-who configuration for a Red Hat hypervisor (Red Hat Enterprise Linux or Red Hat Virtualization Host), register the hypervisor to Red Hat Satellite.
Create a read-only virt-who user on the hypervisor or virtualization manager:
- For Red Hat products and Microsoft Hyper-V, create a virt-who user on each hypervisor that runs Red Hat Enterprise Linux virtual machines.
- For VMware vSphere, create a virt-who user on the vCenter Server. The virt-who user requires at least read-only access to all objects in the vCenter Data Center.
Procedure
- In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
- Click Create Config. In the New Virt-who Config window, you can click the help icons for more information about each field.
- Enter a Name for the configuration.
From the Hypervisor Type list, select your virtualization platform:
- Red Hat Enterprise Linux Virtualization (KVM), Red Hat Virtualization, or Red Hat OpenStack Platform: libvirt
- VMware vSphere: esx
- Microsoft Hyper-V: hyperv
- Note that the rhevm and xen hypervisor types are not supported, and the kubevirt hypervisor type is provided as a Technology Preview only.
- In the Hypervisor Server field, enter the FQDN or IP address of the server this configuration applies to. For VMware vSphere, use the vCenter Server’s FQDN or IP address. For all other products, use the hypervisor’s FQDN or IP address.
- In the Hypervisor Username field, enter the name of the virt-who user that you created on the hypervisor or virtualization manager.
- In the Hypervisor Password field, enter the password for the virt-who user. This password is encrypted when you deploy the configuration. This field is not required when using the libvirt type.
- From the Interval list, select how often virt-who requests new or updated virtual machine information. Because the virtual machines are granted temporary subscriptions for up to seven days, frequent queries are not required; you can select an interval that suits the size of your environment. Every 24 hours is suitable for most environments.
- Enter the Satellite server FQDN.
- From the Hypervisor ID list, select whether to identify the hypervisors in Satellite Server by their host name or UUID.
Select a Filtering option:
- The default is Unlimited. All hypervisors covered by this configuration are queried by virt-who. Use this option if you do not have to limit which hypervisors are queried.
- You can Whitelist or Blacklist hypervisors. For example, if some hypervisors only run Microsoft Windows Server virtual machines, those hypervisors do not need to be reported by virt-who.
- If you selected Whitelist or Blacklist: In the Filter hosts or Exclude hosts field, enter a comma-separated list of hypervisors according to the selected Hypervisor ID. For example, if hypervisors are identified by their host name, they must be included or excluded by their host name. If a hypervisor’s name contains special characters, enclose it in quotation marks. Wildcards and regular expressions are supported. Note that when using regular expressions, backslashes must be escaped.
- If you selected the esx type and Whitelist or Blacklist: In the Filter host parents or Exclude host parents field, enter a comma-separated list of clusters. Hypervisors in a whitelisted cluster are reported by virt-who. Hypervisors in a blacklisted cluster are not reported by virt-who. If a cluster name contains special characters, enclose it in quotation marks. Wildcards and regular expressions are supported. Note that when using regular expressions, backslashes must be escaped.
- Optional: Select the Enable debugging output check box if you require debugging output for troubleshooting.
Optional: Enter an HTTP Proxy to use for communication between the server where virt-who is deployed and the hypervisors or virtualization managers. For example, http://proxy.example.com:3128.
To use no proxy, leave this field blank; this has the same result as entering
*
in the Ignore Proxy field.- Optional: In the Ignore Proxy field, enter a comma-separated list of host names, IP addresses, or domains to bypass existing proxy settings.
- Click Submit.
For CLI Users
On Satellite Server, enter the
hammer virt-who-config create
command. For more information about the options, enterhammer virt-who-config create --help
.This example creates a virt-who configuration for a Red Hat Enterprise Linux hypervisor:
# hammer virt-who-config create \ --name rhel.example.com \ --organization "Example Company" \ --interval 720 \ 1 --filtering-mode none \ 2 --hypervisor-id hostname \ 3 --hypervisor-type libvirt \ 4 --hypervisor-server rhel.example.com \ 5 --hypervisor-username virt-who \ 6 --proxy 'http://proxy.example.com:3128' \ 7 --satellite-url satellite.example.com
- 1
- Choose how often, in minutes, virt-who queries the virtualization platform. Because the virtual machines are granted temporary subscriptions for up to seven days, frequent queries are not required; you can select an interval that suits the size of your environment. Once a day (
1440
) is suitable for most environments. - 2
- Choose whether to filter hypervisors. Use
none
if you do not have to limit which hypervisors are queried. Alternatively, you canwhitelist
orblacklist
hypervisors. For example, if some hypervisors only run Microsoft Windows Server virtual machines, those hypervisors do not need to be reported by virt-who. - 3
- Choose how to identify the hypervisor (or hypervisors) this configuration applies to. Use
hostname
to provide meaningful host names in the Satellite web UI. Alternatively, you can useuuid
to avoid duplication if a hypervisor is renamed.hwuuid
can be used only if this configuration applies to a virtualization manager instead of an individual hypervisor, and must not be changed to another option after virt-who starts running because this causes duplicate entries in Subscription Manager. - 4
- Specify the supported type for your virtualization platform:
-
Red Hat Enterprise Linux Virtualization (KVM), Red Hat Virtualization, or Red Hat OpenStack Platform:
libvirt
-
VMware vSphere:
esx
-
Microsoft Hyper-V:
hyperv
-
Note that the
rhevm
andxen
hypervisor types are not supported, and thekubevirt
hypervisor type is provided as a Technology Preview only.
-
Red Hat Enterprise Linux Virtualization (KVM), Red Hat Virtualization, or Red Hat OpenStack Platform:
- 5
- Specify the FQDN or IP address of the server this configuration applies to. For VMware vSphere, use the vCenter Server’s FQDN or IP address. For all other products, use the hypervisor’s FQDN or IP address.
- 6
- Specify the read-only virt-who user that you created on the hypervisor or virtualization manager. You do not need to specify a password when using the
libvirt
type. For other types, you must specify the virt-who user’s password with the--hypervisor-password
option. - 7
- Optional: Enter an HTTP proxy to use for communication between the server where virt-who is deployed and the hypervisors or virtualization managers.
Chapter 5. Deploying a virt-who Configuration
After you create a virt-who configuration, Satellite provides a script to automate the deployment process. The script installs virt-who and creates the individual and global virt-who configuration files.
For Red Hat products, you must deploy each configuration file on the hypervisor specified in the file. For other products, you must deploy the configuration files on Satellite Server, Capsule Server, or a separate Red Hat Enterprise Linux server that is dedicated to running virt-who.
- To deploy the files on a hypervisor or Capsule Server, see Section 5.1, “Deploying a virt-who Configuration on a Hypervisor”.
- To deploy the files on Satellite Server, see Section 5.2, “Deploying a virt-who Configuration on Satellite Server”.
- To deploy the files on a separate Red Hat Enterprise Linux server, see Section 5.3, “Deploying a virt-who Configuration on a Separate Red Hat Enterprise Linux Server”.
5.1. Deploying a virt-who Configuration on a Hypervisor
Use this procedure to deploy a virt-who configuration on the Red Hat hypervisor that you specified in the file. Global values apply only to this hypervisor.
You can also use this procedure to deploy a vCenter or Hyper-V virt-who configuration on Capsule Server. Global configuration values apply to all virt-who configurations on the same Capsule Server, and are overwritten each time a new virt-who configuration is deployed.
Prerequisites
- Register the hypervisor to Red Hat Satellite.
-
If you are using Red Hat Virtualization Host (RHVH), update it to the latest version so that the minimum virt-who version is available. Virt-who is available by default on RHVH, but cannot be updated individually from the
rhel-7-server-rhvh-4-rpms
repository. - Create a read-only virt-who user on the hypervisor.
- Create a virt-who configuration for your virtualization platform.
Procedure
- In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
- Click the name of the virt-who configuration.
- Click the Deploy tab.
- Under Configuration script, click Download the script.
Copy the script to the hypervisor:
# scp deploy_virt_who_config_1.sh root@hypervisor.example.com:
Make the deployment script executable and run it:
# chmod +x deploy_virt_who_config_1.sh # sh deploy_virt_who_config_1.sh
After the deployment is complete, delete the script:
# rm deploy_virt_who_config_1
5.2. Deploying a virt-who Configuration on Satellite Server
Use this procedure to deploy a vCenter or Hyper-V virt-who configuration on Satellite Server.
Global configuration values apply to all virt-who configurations on Satellite Server, and are overwritten each time a new virt-who configuration is deployed.
Prerequisites
- Create a read-only virt-who user on the hypervisor or virtualization manager.
- If you are deploying a Hyper-V virt-who configuration, enable remote management on the Hyper-V hypervisor.
- Create a virt-who configuration for your virtualization platform.
Procedure
- In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
- Click the name of the virt-who configuration.
- Under Hammer command, click Copy to clipboard.
- On Satellite Server, paste the Hammer command into your terminal.
5.3. Deploying a virt-who Configuration on a Separate Red Hat Enterprise Linux Server
Use this procedure to deploy a vCenter or Hyper-V virt-who configuration on a dedicated Red Hat Enterprise Linux 7 server. The server can be physical or virtual.
Global configuration values apply to all virt-who configurations on this server, and are overwritten each time a new virt-who configuration is deployed.
Prerequisites
- Create a read-only virt-who user on the hypervisor or virtualization manager.
- If you are deploying a Hyper-V virt-who configuration, enable remote management on the Hyper-V hypervisor.
- Create a virt-who configuration for your virtualization platform.
Procedure
On the Red Hat Enterprise Linux server, install Satellite Server’s CA certificate:
# rpm -ivh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
Register the Red Hat Enterprise Linux server to Satellite Server:
# subscription-manager register \ --org=organization_label \ --auto-attach
Open a network port for communication between virt-who and Satellite Server:
# firewall-cmd --add-port="443/tcp" # firewall-cmd --add-port="443/tcp" --permanent
Open a network port for communication between virt-who and each hypervisor or virtualization manager:
- VMware vCenter: TCP port 443
- Microsoft Hyper-V: TCP port 5985
- In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
- Click the name of the virt-who configuration file.
- Click the Deploy tab.
- Under Configuration script, click Download the script.
Copy the script to the Red Hat Enterprise Linux server:
# scp deploy_virt_who_config_1.sh root@rhel.example.com:
Make the deployment script executable and run it:
# chmod +x deploy_virt_who_config_1.sh # sh deploy_virt_who_config_1.sh
After the deployment is complete, delete the script:
# rm deploy_virt_who_config_1
Chapter 6. Registering Virtual Machines to use a Host-based Subscription
Use an auto-attach activation key to register virtual machines so that they inherit a subscription from their hypervisor.
This procedure is only valid if you have Simple Content Access (SCA) disabled on Satellite. You are not required to attach subscriptions to Activation Keys if you have SCA enabled. Instead, follow the Registering Hosts procedure in Managing Hosts to register virtual machines. Note that SCA is enabled by default for newly created organizations. To learn more about SCA, see Simple Content Access.
For more information about activation keys, see Managing Activation Keys in Managing Content.
Prerequisites
- Create an activation key with auto-attach enabled and no subscriptions attached.
- Attach a host-based subscription to the virtual machine’s hypervisor.
- Create and deploy a virt-who configuration that queries the virtual machine’s hypervisor.
Procedure
Configure the virtual machine to register with Satellite Server:
# yum install http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
Register the virtual machine using the auto-attach activation key:
# subscription-manager register --org=organization_label \ --activationkey=activation_key_name
The virtual machine receives a temporary subscription while Satellite Server waits for virt-who to provide information about which hypervisor the virtual machine is running on. After virt-who provides this information, Satellite Server attaches a permanent subscription to the virtual machine.
If the virtual machine migrates to another hypervisor that reports to virt-who and has a host-based subscription attached, the virtual machine inherits a subscription from that hypervisor. If the hypervisor does not have a host-based subscription attached, Satellite Server automatically attaches a host-based subscription to the hypervisor, and the virtual machine inherits that subscription.
If the virtual machine migrates to another hypervisor that does not report to virt-who, or there are insufficient subscriptions available to attach to the hypervisor, the virtual machine cannot inherit a subscription. To avoid this, either ensure that all hypervisors the virtual machine can migrate to have host-based subscriptions attached and report to virt-who, or limit the virtual machine’s migration to specific hypervisors.
Appendix A. Troubleshooting virt-who
A.1. Modifying a virt-who Configuration
You can modify an existing virt-who configuration using either the Satellite web UI or the Hammer CLI. For example, if you need to change how frequently virt-who runs, the virt-who configuration must be updated and deployed again.
Procedure
- In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
- Locate the virt-who configuration you want to modify, and click Edit in the Actions column.
- Edit the fields you want to change.
- Click Submit.
- Redeploy the modified virt-who configuration.
For CLI users
On Satellite Server, enter the
hammer virt-who-config update
command, specifying the name of the configuration you want to modify, and new values for the options you want to change. If you want to change the name of the configuration, you must use the option--new-name
.# hammer virt-who-config update \ --name current_name \ --new-name new_name \ --interval 1440
- Redeploy the modified virt-who configuration.
A.2. Removing an Existing virt-who Configuration
To remove an existing virt-who configuration, you must first remove the configuration entry in the Satellite web UI and then remove the configuration file from the file system of the host that the configuration was deployed on.
Procedure
- In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
- From the Actions list for the configuration you want to remove, select Delete.
On the host that you want to remove the virt-who configuration from, remove the configuration file:
# rm /etc/virt-who.d/conf_name.conf
A.3. Virt-who Troubleshooting Methods
Verifying virt-who status
To verify virt-who’s status in the Satellite web UI, navigate to Infrastructure > Virt-who configurations and check the Status column for each virt-who instance. A status of OK
indicates that virt-who is successfully connecting to Satellite Server and reporting the virtual machines managed by each hypervisor.
To list the status of all virt-who instances using the CLI, enter the following command on Satellite Server:
# hammer virt-who-config list
The command’s output includes the date and time at which each virt-who instance reported to Satellite Server.
Debug logging
Check the /var/log/rhsm/rhsm.log
file, where virt-who logs all its activity by default.
To enable more detailed logging, modify the virt-who configuration:
- In the Satellite web UI, select the Enable debugging output check box.
-
In the Hammer CLI, add the
--debug true
option.
Redeploy the configuration for the change to take effect.
When the underlying issue is resolved, modify the virt-who configuration to disable debugging, then redeploy the configuration again.
Testing configuration options
Make a change and test the result, repeating as needed. Virt-who provides two options to help test the configuration files, credentials, and connectivity to the virtualization platform:
-
The
virt-who --one-shot
command reads the configuration files, retrieves the list of virtual machines and sends it to Satellite Server, then exits immediately. -
The
virt-who --print
command reads the configuration files and prints the list of virtual machines, but does not send it to Satellite Server.
The expected output is a list of hypervisors and their virtual machines, in JSON format. The following is an extract from a VMware vSphere instance. The output from all hypervisors follows the same structure.
{ "guestId": "422f24ed-71f1-8ddf-de53-86da7900df12", "state": 5, "attributes": { "active": 0, "virtWhoType": "esx", "hypervisorType": "vmware" } },
Identifying issues when using multiple virt-who configuration files
If you have multiple virt-who configuration files on one server, move one file at a time to a different directory while testing after each file move. If the issue no longer occurs, the cause is associated with the most recently moved file. After you have resolved the issue, return the virt-who configuration files to their original location.
Alternatively, you can test an individual file after moving it by using the --config
option to specify its location. For example:
# virt-who --debug --one-shot --config /tmp/conf_name.conf
Identifying duplicate hypervisors
Duplicate hypervisors can cause subscription and entitlement errors. Enter the following commands to check for duplicate hypervisors:
# systemctl stop virt-who # virt-who -op >/tmp/virt-who.json # systemctl start virt-who # cat /tmp/virt-who.json | json_reformat | grep name | sort | uniq -c | sort -nr | head -n10 3 "name": "localhost" 1 "name": "rhel1.example.com" 1 "name": "rhel2.example.com" 1 "name": "rhel3.example.com" 1 "name": "rhel4.example.com" 1 "name": "rhvh1.example.com" 1 "name": "rhvh2.example.com" 1 "name": "rhvh3.example.com" 1 "name": "rhvh4.example.com" 1 "name": "rhvh5.example.com"
In this example, three hypervisors have the same FQDN (localhost
), and must be corrected to use unique FQDNs.
Identifying duplicate virtual machines
Enter the following commands to check for duplicate virtual machines:
# systemctl stop virt-who # virt-who -op >/tmp/virt-who.json # systemctl start virt-who # cat /tmp/virt-who.json | json_reformat | grep "guestId" | sort | uniq -c | sort -nr | head -n10
Checking the number of hypervisors
Enter the following commands to check the number of hypervisors virt-who currently reports:
# systemctl stop virt-who # virt-who -op >/tmp/virt-who.json # systemctl start virt-who # cat /tmp/virt-who.json | json_reformat | grep name | sort | uniq -c | wc -l
Checking the number of virtual machines
Enter the following commands to check the number of virtual machines that virt-who currently reports:
# systemctl stop virt-who # virt-who -op >/tmp/virt-who.json # systemctl start virt-who # cat /tmp/virt-who.json | json_reformat | grep "guestId" | sort | uniq -c | wc -l
A.4. Virt-who Troubleshooting Scenarios
Virt-who fails to connect to the virtualization platform
If virt-who fails to connect to the hypervisor or virtualization manager, check the Red Hat Subscription Manager log file /var/log/rhsm/rhsm.log
. If you find the message No route to host
, the hypervisor might be listening on the wrong port. In this case, modify the virt-who configuration and append the correct port number to the Hypervisor Server value.
You must redeploy the virt-who configuration after modifying it.
Virt-who fails to connect to the virtualization platform through an HTTP proxy on the local network
If virt-who cannot connect to the hypervisor or virtualization manager through an HTTP proxy, either configure the proxy to allow local traffic to pass through, or modify the virt-who configuration to use no proxy.
You must redeploy the virt-who configuration after modifying it.
Virt-who fails to report back the host-guest mapping to Red Hat Satellite server
Virt-who fails to report back the host-guest mapping to Red Hat Satellite server in the following circumstances.
- virt-who is configured and deployed on Red Hat Satellite server.
-
The
rhsm.conf
file of Red Hat Satellite server is configured to use a proxy server to talk to subscription.rhsm.redhat.com and cdn.redhat.com. -
The
no_proxy=*
setting in/etc/sysconfig/virt-who
is present but being ignored by subscription-manager, and virt-who attempts to connect back to Satellite server through a proxy server but fails.
In this case, add the following parameter to the /etc/rhsm/rhsm.conf
file.
no_proxy = satellite.example.com