Configuration of virt-who to support Red Hat Virtualization.
Overview
This article describes how to configure virt-who with Red Hat Virtualization & Red Hat Enterprise Virtualization
Background
There are fundamentally 2 different types of hypervisors that can be used with RHEV.
RHEV 3 provides two different hypervisor types (excerpted from the This content is not included.RHEV 3 Installation Guide):
-
Red Hat Enterprise Virtualization Hypervisor (aka RHEV-H, thin host) -
This is a minimal operating system based on Red Hat Enterprise Linux. It is distributed as an ISO file and is a closed system. Filesystem access and root access are limited. Yum is disabled. -
Red Hat Enterprise Linux Host (aka RHEL-based hypervisor, thick host) - Red Hat Enterprise Linux hosts subscribed to the appropriate channels can be used as hypervisor hosts. It provides you the full access to the operating system.
Red Hat Virtualization (RHV) version 4 provides the above two hypervisor types which are slightly different than before (excerpted from the This content is not included.RHV 4 Installation Guide):
Red Hat Virtualization 4.0 introduces an upgraded version of the Red Hat Enterprise Virtualization Hypervisor. While the previous RHEV-H was a closed system with a basic text user interface for installation and configuration, Red Hat Virtualization Host (RHVH) can be updated via yum and uses an Anaconda installation interface based on the one used by Red Hat Enterprise Linux hosts.
With RHV4, it is expected that a user registers the hypervisor (regardless of type) via subscription-manager.
Impact on the configuration of virt-who.
As there are different types of hypervisors, the configuration of virt-who differs.
Effectively there are three hypervisor types (and the latter two, for the purposes of subscription management, function the same):
- RHEV-H (RHEV [version 3] appliance-style hypervisor)
- RHVH (RHV [version 4] 'appliance'). RHVH is not as restricted in its configuration options as RHEV-H was. Primarily, it has
subscription-managerandvirt-whoinstalled by default, and it is expected that RHVH is registered to Satellite 6. - RHEL-based hypervisor (which is functionally the same in RHEV and RHV)
virt-who has the following configuration types that apply to RHEV and RHV hypervisors:
- rhevm
- vdsm
- libvirt
Which hypervisor mode to use (and why you'd use it) can be confusing. This document aims to disambiguate the configuration of virt-who for both RHEV and RHV customers.
General configuration notes
-
RHEV-H - As this hypervisor cannot be registered (to Satellite), rhevm mode is ideal here, as the hypervisor's Operating System never needs content (and thus won't need a subscription attached). This is effectively just like esx mode in virt-who. (One system polls the hypervisor management platform and gets host/guest mapping for ALL hypervisors)
-
RHVH and RHEL-based Hypervisors - As these hypervisors can be registered (to Satellite) via subscription-manager, configuring virt-who on each hypervisor (in either libvirt or vdsm mode) makes the most sense here. The downside here is configuring virt-who on each hypervisor.
Configuration for RHEV-H hypervisors.
If your deployment contains ONLY RHEV-H hypervisors, follow the directions in section 5.3 of This content is not included.Satellite 6 Virtual Instance Guide
Note, additional configuration is required for RHV version 4 This content is not included.see BZ1415497
RHV-H and RHEL-based hypervisors
Virt-Who Installation
If your deployment contains ONLY RHV-H or RHEL-based hypervisors, install virt-who on EACH hypervisor like so:
yum -y install virt-who
systemctl enable virt-who #or chkconfig virt-who on for RHEL6
systemctl start virt-who #or service virt-who start for RHEL6
Configuration
If your deployment contains ONLY RHV-H or RHEL-based hypervisors, configure EACH hypervisor as per the directions in section 5.4 of the This content is not included.Satellite 6 Virtual Instance Guide
NOTE: the default configuration of virt-who is to query guests via the libvirt module, and report them to the system it is registered to, using its This content is not included.Identity Certificate for authentication.
Configuration for mixed environments
If your deployment contains RHEV-H and either RHVH or RHEL-based hypervisors, a mixed configuration is needed.
In this scenario, you'd configure virt-who as illustrated above for each respective hypervisor type.
Additionally, you should use filtering in the virt-who configuration that is in rhevm mode to either include only the RHEV-H hypervisors or exclude the RHVH/RHEL-based hypervisors.
If filtering is not setup in mixed environments, the RHV-H or RHEL-based hypervisors will be reported twice, (once via virt-who in rhevm mode and once via virt-who in libvirt/vdsm mode). This is not ideal as the subscription that provides content to the hypervisor is usually also the same subscription that provides content to the guest. As subscriptions cannot be split across what are effectively two systems, this situation is best avoided.
Filtering in virt-who can be accomplished by either of the following directives:
filter_hosts
Only hosts which uuid (or hostname or hwuuid, based on
hypervisor_id) is specified in comma-separated list in
this option will be reported. Put the value into the
double-quotes if it contains special characters
(like comma). filter_host_uuids is deprecated alias for
this option.
exclude_hosts
Hosts which uuid (or hostname or hwuuid, based on hypervisor_id)
is specified in comma-separated list in this option will NOT
be reported. Put the value into the double-quotes if it contains
special characters (like comma). exclude_host_uuids is
deprecated alias for this option
Example configuration:
$cat /etc/virt-who.d/rhevm.conf
[rhev-farm]
# type = esx,rhevm,libvirt,vdsm
type=rhevm
# server (append /ovirt-engine for RHV4 - see bz1415497)
server=https://rhevm.example.com:443/ovirt-engine/
#server=https://rhevm.example.com:443/
# username syntax for Active Directory users is either
# UPN based = user@domain.com
# NETBIOS based = domain\user.
username=admin@internal
# Get encrypted password from virt-who-password
#encrypted_password=[REDACTED]
# Organization Label in Satellite 6 where the hypervisors
# should be reported to.
owner=Example
# Note, do NOT use any env other than Library or virt-who will fail
#(bz1283740)
env=Library
# Report hypervisors with hostname and not UUID because UUIDs are ugly.
hypervisor_id=hostname
# Hostname of Satellite
rhsm_hostname=satellite.example.com
# Username in Satellite
rhsm_username=admin
# Again, use virt-who-password to create.
rhsm_encrypted_password=[REDACTED]
# Prefix. (set to /rhsm for Satellite 6)
rhsm_prefix=/rhsm
#### Filtering
# filter_hosts = whitelist
filter_hosts = rhev-h1.example.com,rhev-h2.example.com, other_hosts_that_will_be_reported
# OR
# exclude_hosts = blacklist
exclude_hosts = rhv-1.example.com,other_hosts_not_to_be_reported.
For more KB articles/solutions related to Virt-who and Virtual Datacenter (VDC) Subscriptions Issues, please refer to the Consolidated Troubleshooting Article for Virt-who and Virtual Datacenter (VDC) Subscriptions Issues