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.
À propos de l'auteur
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit