Virtual Instances Guide

Supported virtualization platforms to which a Virtual Data Center (VDC) subscription can be applied are:

A VDC subscription applies only to a hypervisor’s guest virtual machines, not the hypervisor itself. For all virtualization platforms which require a Red Hat Enterprise Linux hypervisor, the hypervisor requires its own subscription.

Red Hat recommends a subscription that allows virtual machines to inherit subscriptions, since this allows for flexibility when provisioning virtual machines. However the choice is yours, and should be made according to your requirements. If you are unsure which subscription best meets your needs, contact your Red Hat account manager for advice. For more details of the Red Hat subscription model, see Subscription Concepts and Workflows.

The following are example Red Hat subscriptions which provide inheritable subscriptions:

This guide uses a Red Hat Enterprise Linux for Virtual Datacenters (VDC) subscription in all examples. The workflow for all inheritable subscriptions is identical.

Confirming if virt-who is Required

To confirm if the virt-who daemon is required, either use the Red Hat Certificate Tool, or contact Red Hat Support. The command line Red Hat Certificate Tool (rct) reads a Subscription Manifest file and displays details of the manifest in plain text. The Red Hat Certificate Tool is available in subscription-manager-1.17.10 (or later) package, in either Red Hat Enterprise Linux 7.3 or Fedora 24.

The virt-who daemon is required if the rct output includes Virt Limit: unlimited, Requires Virt-who: True, or both. In this example, both are included, confirming that the virt-who daemon is required.

A Virtual Data Center (VDC) subscription is one type of host-based subscription offered by Red Hat. Host-based subscriptions are applied to a host and inherited by its guests. Host-based subscriptions consist of two parts, a pool attached to the virtualization manager or hypervisor, and a pool from which virtual guests inherit their subscription. It is important to note that the virtualization manager or hypervisor’s subscription does not provide entitlement to product content.

To successfully provision virtual machines, and ensure they inherit host subscriptions, you must do the following:

A registered host, virtual or physical, has a subscription status based on its installed Products and attached subscriptions.

To verify the status of a virtual machine’s subscription in the Satellite web UI:

The simplest configuration requiring virt-who consists of one hypervisor or virtualization manager, one organization, and one hypervisor technology, with the virt-who instance reporting directly to the Satellite Server. Since most organizations are more complex than this, the configuration of virt-who can be adapted to accommodate the following variables:

Before proceeding to install virt-who, ensure the following prerequisites are met.

Complete this procedure to create a virt-who configuration, using the Satellite web UI.

Create virt-who Configuration using the web UI

To create a virt-who configuration using the Satellite web UI:

Complete this procedure to create a virt-who configuration using the Hammer CLI tool.

For more details about using the Hammer CLI tool, see the Hammer CLI Guide.

Create a virt-who configuration using Hammer

Run the hammer subcommand virt-who-config create.

# hammer virt-who-config create \
  --name rhevm.example.com \ 1
  --organization "Example Company" \ 2
  --interval 120 \ 3
  --filtering-mode none \ 4
  --hypervisor-id hostname \ 5
  --hypervisor-type rhevm \ 6
  --hypervisor-server rhevm.example.com \ 7
  --hypervisor-username virt-who-user \ 8
  --hypervisor-password virt-who-password \ 9
  --satellite-url satellite.example.com 10

If the creation is successful, a message like the following is output.

Virt Who configuration [rhevm.example.com] created

Complete this procedure to deploy a virt-who configuration. The virt-who service is started when a virt-who configuration is deployed.

Deploy virt-who Configuration

To deploy a virt-who configuration:

It is sometimes necessary to modify a deployed virt-who configuration. For example, when the password of the user with which virt-who connects to a hypervisor is changed, the virt-who configuration must be updated and deployed again.

An existing virt-who configuration can be modified using either the Satellite web UI or with hammer.

Modify a virt-who Configuration

# systemctl restart virt-who.service

# service virt-who restart

Repeat these steps for each hypervisor.

To confirm that the VDC subscription and its associated subscription pool are available, open the Satellite web UI and navigate to Content > Subscriptions. For example, if you have a single virtualization manager or hypervisor registered with a VDC subscription, its subscription pool is listed as follows:

Red Hat Enterprise Linux for Virtual Datacenters, Standard

1 out of 1				Physical

The subscriptions pool is listed under the VDC subscription as follows:

Red Hat Enterprise Linux for Virtual Datacenters, Standard (DERIVED SKU)

1 out of unlimited		Guests of vmhost1.example.com

In this example, one virtual machine has been subscribed and inherited its subscription from the hypervisor vmhost1.example.com. To confirm which virtual machines are subscribed, click on the subscriptions count (in this example, 1 out of unlimited), and from the Activation Key drop-down list select Content Hosts.

The process of registering a virtual machine is as follows:

Use the following procedure to register guest virtual machines.

You can also use an activation key with Red Hat Satellite. For more information about activation keys, see Managing Activation Keys in the Content Management Guide.

Verifying the status of all virt-who instances is the recommended first step in troubleshooting. All virt-who instances configured and deployed using either the Satellite web UI or hammer are reported in the Satellite web UI. Those virt-who instances which were configured manually are not available in the Satellite web UI.

# hammer virt-who-config list

By default, virt-who logs all its activity to the file /var/log/rhsm/rhsm.log. When troubleshooting, check the log file as this might reveal useful information. To enable more detailed logging, change the debugging line in the global configuration file /etc/sysconfig/virt-who to VIRTWHO_DEBUG=1. If virt-who is running as a service, you must restart it for the configuration change to take effect. When you have resolved the underlying issue, disable diagnostic logging by changing the debugging line back to VIRTWHO_DEBUG=0 and restarting the virt-who service.

Since there can be multiple configuration files, both global and hypervisor-specific, duplicate configuration lines might result in virt-who behaving differently to what you intend.

To detect duplicate lines in the virt-who configuration files, use the following command. The output of this command is a list of all lines in the specified files, prefixed by the number of times it occurs. Check all instances where the same line is listed as occurring twice or more, remove the duplicate line and restart the virt-who service. For instructions see Section 3.4.1, “Restarting the virt-who Service”.

# cat /etc/sysconfig/virt-who /etc/virt-who.d/* | sort | uniq -c

The comment character # must be the first character on the line in a configuration file. Any white space at the start of the line results in the line being included in the configuration.

Incorrect credentials can be a source of virt-who failure. If possible, test the credentials configured for use by virt-who by logging in to the virtualization manager or hypervisor. For example, if you can log in to the VMware vSphere management console and the expected hosts are visible, then credentials are correct.

When troubleshooting, a common method of determining the root cause of a problem is to make a change and test the result, repeating as needed. The virt-who agent provides an option to help with this technique.

Run the command virt-who --one-shot which reads all configuration files, retrieves the list of virtual machines from all sources, then exits immediately. This tests the configuration files, credentials and connectivity to configured virtualization platforms.

# virt-who --one-shot

The output you can expect is a list of hypervisors and the hosted guest virtual machines, in JSON format. The following is an extract from virt-who output 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"
    }
},

If you have multiple virt-who configuration files, move one virt-who configuration file at a time to your /root 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.

This section covers three methods to reattach subscriptions for multiple hosts. The following use cases apply:

If host subscriptions have expired, but you have configured auto-attach and virt-who previously, subscription manager will attempt to reattach a valid subscription that covers the host and its virtual machines based on a set of criteria. No action is required.