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

  1. In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
  2. Locate the virt-who configuration you want to modify, and click Edit in the Actions column.
  3. Edit the fields you want to change.
  4. Click Submit.
  5. Redeploy the modified virt-who configuration.

For CLI users

  1. 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
  2. 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

  1. In the Satellite web UI, navigate to Infrastructure > Virt-who configurations.
  2. From the Actions list for the configuration you want to remove, select Delete.

  3. 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.

  1. virt-who is configured and deployed on Red Hat Satellite server.
  2. 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.
  3. 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