Subscription-manager for the former Red Hat Network User: Part 3 - Understanding virt-who

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Overview

In Subscription-manager for the Former Red Hat Network User, part 1 & part 2, we covered an introduction to the client-side tooling . This article aims to cover virt-who, a critical component of the server-side Subscription Management tooling.

What is virt-who?

With the introduction of the 2010 subscription model, Red Hat introduced subscriptions, where the customer could buy a single subscription (for a hypervisor) which allowed 1, 4 or unlimited virtual guests to run on that hypervisor (with no additional purchase required). With the 2013 subscription model, we continued that methodology with the advent of the Virtual Datacenter (VDC) Subscription. The business terms that the subscription is sold in state 'For a hypervisor $foo, you can instantiate 1, 4 or unlimited guests (depending on the subscription) on this hypervisor (and this hypervisor only)'. How did one account for which hypervisor does each virtual machine runs on?

How does virt-who work?

virt-who is an daemon, installable on 1 or more Red Hat Enterprise Linux systems, which retrieves host-guest mapping information from 1 or more hypervisor management platforms. It does two major tasks:

• Retrieve the mapping of which virtual guests is a hypervisor running, either by running:
  • Locally on the hypervisor (RHEL+KVM, RHEL-OSP, or RHEL-H)
  • Via the hypervisors management platform (RHEV with 2013 subs or RHEV-H, vSphere, Hyper-V)
• Report the host-guest mapping to a Subscription Management System (Satellite 6, SAM or Red Hat Subscription Management (RHSM)) at a defined internal (3600 Seconds / 1 hour by default)

When do I need virt-who:

If you have a subscription with 'Virtual Datacenters', '4 Guests' or 'Unlimited Guests' in the name, you'll need virt-who. If one of the aforementioned subscriptions are in usage, virt-who is required regardless of the hypervisor. Now, which hypervisor is in use determines how virt-who is configured. Configuring virt-who is beyond the scope of this document. That is covered in the Installation Guide. This document aims to state the current state of affairs, with a slight bias towards how virt-who works with Satellite 6.0 & 6.1.

Where do I find virt-who

virt-who is packaged in a couple of places. It is shipped as a component of RHEL and Satellite. It is shipped in the Satellite Tools repositories (rhel-*-server-satellite-tools-6.*-rpms) so that it can be updated outside of the RHEL release cycle. Otherwise, there is no difference (other than a nominal difference in versions)

Where should I install virt-who?

It is expected that virt-who has access to connect over the network to the hypervisor and Satellite's API port (443). Any of the following can be used as a system to run virt-who on

• The Red Hat Satellite Server itself. (NOTE: requires virt-who >= 0.14)
• Red Hat Satellite Capsule Servers
• Any system registered to the Satellite server that has the appropriate network connectivity.

Understanding Provisioning with VDC/Unlimited Subscriptions

Remember that the virtual datacenter subscriptions come with the requirement that the hypervisor upon which a guest is residing is known. There is a key difference in behavior between Satellite 6.0 and 6.1 in this area that makes provisioning work more smoothly. For the next two examples, it is assumed that the user has properly setup provisioning, and is using an activation key so that guests can register using a VDC sub.

Satellite 6.0 provisioning with virt-who & vDC subscriptions

In Satellite 6.0, the process was as follows:

• User provisioned a system onto a hypervisor, either via a compute resource or via PXE/ISO.
• The system installs packages from the HTTP kickstart repositories.
• virt-who runs & retrieves the host-guest mapping. "Virtual machine $foo resides on hypervisor $bar"
• virt-who reports this information to Satellite
• The guest, In the %post section of its kickstart, runs subscription-manager register using the activation key that the administrator wanted.

These steps needed to happen in EXACTLY that order. In practice there were a number of challenges with this:

• With the default configuration of virt-who, the daemon only polls the hypervisors every 3600 seconds (once an hour). Thus, the likelihood of getting a successful run of virt-who that was after the VM was created and before it registered was extremely low. This race condition could be addressed in one of two ways:
  • Speeding up virt-who (change VIRTWHO_INTERVAL in /etc/sysconfig/virt-who)
  • slowing down provisioning (adding an artificial wait in the provisioning template)
• Virtual Machines very frequently are migrated in virtualization clusters, either manually, or via automated processes, such as VMWare's DRS. The hypervisor that a virtual machine is instantiated on, might not be the hypervisor is it residing on when it attempts to register to Satellite.

When the above workflow did not happen, system registration would fail because Satellite believed (based on incorrect and/or not-current data from virt-who) that the host/guest mapping for the guest is unknown. Thus, the guest could not use the subscription of the hypervisor. virt-who was in the critical path of registering new systems, and there are a number of variables that

Satellite 6.1 provisioning with virt-who & vDC subscriptions

Satellite 6.1 makes a number of significant improvements with provisioning behavior. The underlying process changes.

• User provisioned a system onto a hypervisor, either via a compute resource or via PXE/ISO. The system installs packages from the HTTP kickstart repositories.
• The guest, In the %post section of its kickstart, runs subscription-manager register using the activation key that the administrator wanted
• virt-who runs & retrieves the host-guest mapping. "Virtual machine $foo resides on hypervisor $bar"
• virt-who reports this information to Satellite.
• Guest subscription is refreshed with the proper sub. Later.

Firstly, virt-who is moved out of critical path of registration. So, what changed? Firstly, Candlepin (the subscription management backed) got a pretty significant change. In Satellite 6.1, a guest attempting to register with a vDC subscription is granted a 24 hour subscription if the host the guest is running on is unknown at registration time. The basic workflow, if envisioned as conversation would appear as such :

• Client: "Hi Satellite, I want to register using this activation key"
• Satellite: "Well, according to my records, you don't reside on $bar, but you look like an upstanding virtual machine. I'll issue you a subscription for the next 24 hours, while we figure this out.
• Satellite (on the phone): "Hey, virt-who, can you get confirmation as to whether or not this virtual machine exists and which hypervisor does it run on"
• virt-who: "Yes, Satellite, he's good"

This allows transient failures of virt-who to be non-critical and allows provisioning to $JUST_WORK. In this usage, the guest is flagged as yellow within the Satellite interface until its host-guest mapping data is known.

Do I need to change my provisioning workflow?

Possibly. It is expected (and required) to have virt-who properly configured and running so that host-guest mappings are reported. However, it is advised to review your activation keys to ensure that they are having the desired effects. In addition to the 24 hour subscription, activation keys have been made more flexible with the following use-cases:

• Use Case 1: Use EXACTLY the subscriptions specified (this was 6.0's behavior)
• Use Case 2: Define NO subscriptions, and auto-attach a subscription based upon installed products
• Use Case 3: Use ANY of a subset of subs

How do I know if I am using a temporary subscription?

You can verify if a system is using a temporary subscription using the subscription-manager command.

subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:   Red Hat Enterprise Linux for Virtual Datacenters, Standard (DERIVED SKU)
Provides:            Oracle Java (for RHEL Server)
                     Red Hat Developer Toolset (for RHEL Server)
                     Red Hat Software Collections Beta (for RHEL Server)
                     Red Hat Software Collections (for RHEL Server)
                     Red Hat Enterprise Linux Server
                     Red Hat Beta
SKU:                 RH00050
Contract:            11223344
Account:             123456
Serial:              3612195931191875279
Pool ID:             2c91809352db8ab10152db9186d80bde
Provides Management: Yes
Active:              True
Quantity Used:       1
Service Level:       Standard
Service Type:        L1-L3
Status Details:      Guest has not been reported on any host and is using a temporary unmapped guest subscription.
Subscription Type:   Stackable (Temporary)
Starts:              08/05/2015
Ends:                03/06/2016
System Type:         Virtual

OR

subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Insufficient

Red Hat Enterprise Linux for Virtual Datacenters, Standard (DERIVED SKU):
- Guest has not been reported on any host and is using a temporary unmapped guest subscription.

In the world of subscription-management, there are three statuses that a system can be in:

• Red = Invalid - Action is immediately required. The system in question has products installed that valid subscriptions do not cover. Systems in a 'Red' status do not have access to content for the products that subscriptions are not installed for.
• Yellow = Insufficient - Action is potentially required soon. Systems that are in a Yellow/Insufficient state have access to content for the products that are installed. However, further investigation is advised so the system can attain a Green/Valid status. A system can be flagged as 'yellow' under a number of conditions:
  • If a system has the correct type, but incorrect quantity of a subscription attached. (i.e. you attached a 2-socket sub to a 4-socket system)
  • If the hypervisor that a virtual guest is residing on at the time the system is registered is unknown.
• Green - Valid - No action is required. The system in question has valid subscriptions for all of the products that are installed

What actions do I need to take if system is using a temporary subscription?

It is expected that virt-who is installed and running so that guests can properly use Virtual Datacenter / Unlimited subscriptions. For a given guest, the possible actions are as follows:

• Do not install virt-who and nothing. After 24 hours, the guest will attach a subscription from the list of available subscriptions in your account / organization. Note: guests may consume physical subscriptions OR 1 virtual datacenter subscription EACH. (This is non-desired and is mentioned only to describe the expected behavior)
• Install virt-who and then do nothing. Installing virt-who reports to RHSM or Satellite 6.1 on which hypervisor a guest runs on. Once virt-who is running, generally no further action is required. When the temporary subscription expires, the guest will attach a virtual subscription based upon the hypervisor it runs on.
• Install virt-who and explicitly change the subscription. If you either don't wish to wait 24 hours OR you want to be more granular as to which subscription is used, install & configure virt-who, and then update the guest to use whichever subscription you like.

Hopefully, this document helps to with understanding virt-who and its usage in your deployments.

Further Reading

• Chapter 6 - Satellite 6.1 Installation Guide
• KCS 1615073 - How to make virt-who report hypervisors hostnames instead of UUID to Satellite 5 or Satellite 6
• KCS 2109221 - How to install and configure virt-who on Red Hat Satellite 6.1, without registering Satellite to itself.