Chapter 2. Virt-who Installation and Configuration Overview

PDF

For a virtual Red Hat Enterprise Linux server to request and be granted a VDC subscription, the virt-who daemon must be configured to connect to each virtualization manager or hypervisor and report hosted virtual machines to Red Hat Satellite Server 6. To establish these connections, complete the following tasks in order:

Decide on a configuration that suits your environment.
Review the virt-who daemon’s prerequisites and ensure that all have been met.
If the virt-who daemon is not to be installed on either the Satellite Server or an external Capsule Server, install an instance of Red Hat Enterprise Linux for the purpose.
Install the virt-who daemon.
Create a virt-who configuration
Deploy the virt-who configuration
Establish connections between the virt-who daemon and your hypervisors.

2.1. Configuration Options

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:

Multiple organizations in Satellite
Multiple hypervisors
Multiple hypervisor technologies
HTTP proxy

2.1.1. Multiple Organizations

A single virt-who instance can report to the Satellite Server virtual machines which are associated with multiple organizations. Red Hat recommends one organization per virt-who configuration file.

2.1.2. Multiple Hypervisors

A single virt-who instance can connect to multiple hypervisors and report the virtual machines hosted by each. Red Hat recommends one hypervisor or virtualization manager per virt-who configuration file.

If you have multiple hypervisors, virt-who queries each in parallel. This reduces the chance of virt-who’s queries being stopped or delayed because of an unresponsive hypervisor.

2.1.3. Multiple Hypervisor Technologies

A single virt-who instance can connect to multiple hypervisors from different vendors. Red Hat recommends one hypervisor technology per virt-who configuration file.

2.1.3.1. Red Hat Hypervisors

Red Hat Virtualization (version 4.0 and later) and Red Hat Enterprise Virtualization (version 3.6 and earlier) are enterprise-grade server and desktop virtualization platforms built on Red Hat Enterprise Linux. Both products are supported by virt-who. The type and quantity of Red Hat hypervisors you have determines the installation process for virt-who. For more information, see Section 2.2, “Prerequisites”.

2.1.3.1.1. Red Hat Enterprise Virtualization (version 3.6 and earlier)

Red Hat Enterprise Virtualization (version 3.6 and earlier) includes two types of hypervisors:

Red Hat Enterprise Virtualization hypervisor (RHEV-H): This is a minimal operating system based on Red Hat Enterprise Linux. Filesystem access and root access are limited. Updates via yum are not possible.
Red Hat Enterprise Linux host (RHEL-H): This is a Red Hat Enterprise Linux host which is subscribed to specific software channels, and has the hypervisor packages installed.

2.1.3.1.2. Red Hat Virtualization (version 4.0 and later)

Red Hat Virtualization (version 4.0 and later) includes two types of hypervisors:

Red Hat Virtualization host (RHVH): This is a minimal operating system based on Red Hat Enterprise Linux. Unlike RHEV-H, a Red Hat Virtualization host can be updated via yum. It has subscription-manager and virt-who installed by default. This type of hypervisor should be registered to Satellite Server.
Red Hat Enterprise Linux host (RHEL-H): This is a Red Hat Enterprise Linux host which is subscribed to specific software channels, and has the hypervisor packages installed. This type of hypervisor is equivalent to the RHEL-H hypervisor of Red Hat Enterprise Virtualization (version 3.6 and earlier).

2.1.4. Installation Locations

Where you install virt-who, and whether one or multiple instances are required, is determined by your hypervisors and virtualization managers. For Microsoft Hyper-V and VMware vSphere, install virt-who on either the Satellite or a dedicated instance of Red Hat Enterprise Linux. For Red Hat hypervisors the decision requires more analysis.

2.1.4.1. RHEV-H

If you have RHEV-H hypervisors, install virt-who on either the Satellite or a dedicated instance of Red Hat Enterprise Linux.

2.1.4.2. RHV-H

If you have RHV-H hypervisors, install virt-who on each RHV-H hypervisor and register the hypervisor to Satellite Server.

2.1.4.3. Only RHEL-H

If you have RHEL-H hypervisors, install virt-who on each RHEL-H hypervisor and register the hypervisor to Satellite Server.

2.1.4.4. Mixed Red Hat Hypervisors

If you have multiple Red Hat hypervisor types, some additional configuration is required to prevent duplicate hosts being reported.

Total the number of RHVH, RHEL-H, and RHEV-H hypervisors in your environment.

If the number of RHVH and RHEL-H hypervisors is greater than the number of RHEV-H hypervisors, exclude all RHEV-H hypervisors from being reported by virt-who.
If the number of RHEV-H hypervisors is greater than the number of RHVH and RHEL-H hypervisors, exclude all RHVH and RHEL-H hypervisors.

For details on how to exclude specific hypervisors, see Section 2.1.5, “Filtering Scope of virt-who Access”.

2.1.5. Filtering Scope of virt-who Access

In a hybrid environment, with virtual machines running Red Hat Enterprise Linux and other operating systems, you can exclude some hosts from virt-who. For example, if some hypervisors host only Microsoft Windows Server instances, there is no benefit in having those hosts reported by the virt-who agent.

To reduce the number of hosts reported by virt-who, use one or both of the following methods. Each method achieves the same objective, but the filter method should be considered the default since it is a native feature of virt-who.

Filter hosts to be included or excluded.
Limit access to a subset of hosts.

2.1.5.1. Filter Hosts

For each virt-who instance, you can filter the hosts to be reported by virt-who to the Satellite Server. The hosts listed are either excluded or included. Only one filtering method per virt-who instance is valid.

Provide a comma-separated list of hosts to be blacklisted or whitelisted when configuring virt-who. Wildcards and regular expressions are supported. If a host’s name contains special characters, enclose it in quotation marks.

Hosts discovered by virt-who are identified in Satellite by either their host name, which is recommended and the default, or unique ID. Hosts must be filtered according to the method used to identify them. For example, if they are identified by their host name, they must be excluded or included by their host name.

2.1.5.2. Limit Access to Specific Hosts

Grant the account used by virt-who read-only access to only those hosts you want to include. With restricted access to hosts, the virt-who daemon will only find and retrieve those hosts accessible to it.

2.1.6. HTTP Proxy

If you use HTTP proxy servers in your environment, additional configuration is required to use virt-who with HTTP proxy:

If there is an HTTP proxy between Satellite and the Content Delivery Network (CDN), by default, the virt-who traffic will attempt to go through the proxy server as well. This often fails if the HTTP proxy is configured to allow only external traffic and not internal traffic (virt-who traffic). It is also likely to fail if Satellite Server is on the same local network as the hypervisors.
To workaround these issues, you can configure virt-who to use no proxy, configure the HTTP proxy to allow local network traffic through, or configure an additional squid proxy. For further details, see Section 5.8.3, “Virt-who attempts to connect to virtualization manager or hypervisor via an HTTP proxy on the local network fails”.
If you require virt-who to use a different proxy than what Satellite Server uses to connect to external networks, see Section 5.8.4, “Configure virt-who to use an internal proxy” for further details.

2.2. Prerequisites

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

2.2.1. Authentication Requirements

Each virt-who instance requires read-only access to each virtualization manager or individual hypervisors, and write access to the Satellite Server.

Hypervisor

Create an account with read-only access to each virtualization manager, such as VMware vCenter, or individual hypervisors. With this access, virt-who retrieves the list of guest virtual machines and reports this to Satellite Server. For VMware vCenter, also VMware ESXi, the virt-who user requires at least read-only access to all objects within the virtualization manager. If you have multiple clusters, hypervisors, and virtual machines within your VMware virtualization manager, the virt-who user requires at least read-only access to all objects representing those resources.

Each connection is separate, so you can use different accounts for each virt-who instance if required. Each account, generally known as a service account, must be dedicated to this purpose, have read-only access, and have a non-expiring password.

Warning

An account with read-only access to Red Hat Virtualization Manager is not sufficient. To be able to acquire the Red Hat Virtualization Hypervisor host information via virt-who, it is necessary to create a new role in the Red Hat Enterprise Virtualization environment with the Admin account type and Login Permissions enabled only and assign this role to the account.

Red Hat Satellite

Every virt-who configuration, created using either the Satellite web UI or hammer, creates a unique service user for virt-who authentication. The user is named virt_who_reporter$id and has a randomly generated password. The virt-who user is assigned the Virt-who Reporter role, which provides minimal permissions, allowing the user to only perform virt-who reporting. No manual configuration of these accounts is possible, and they cannot be used to login to the Satellite Server.

2.2.2. Software Requirements

Red Hat recommends installing virt-who on the Satellite Server, because it simplifies the network configuration and provides maximum availability. However, for Red Hat Enterprise Linux hypervisors, the virt-who daemon must be installed on the hypervisor. Alternatively, virt-who can be installed on an external Capsule Server, or a dedicated instance of Red Hat Enterprise Linux 7 (recommended) or Red Hat Enterprise Linux 6.

Complete the following procedure if you are installing virt-who on a dedicated instance of Red Hat Enterprise Linux.

Preparing virt-who Host

Install Red Hat Enterprise Linux, version 7 (recommended) or 6.
Only a CLI environment is required. For help with this step, see the Red Hat Enterprise Linux 7 Installation Guide or the Red Hat Enterprise Linux 6 Installation Guide.

Install the Satellite Server’s CA certificate:

# rpm -ivh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm

# subscription-manager register \
--username=username \
--password=password \
--org=organization_label \
--auto-attach

Open a network port for communication between virt-who and the subscription service:

On Red Hat Enterprise Linux 7:

# firewall-cmd --add-port="443/tcp"
# firewall-cmd --add-port="443/tcp" --permanent

On Red Hat Enterprise Linux 6:

# iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
# service iptables save

Open a corresponding network port for communication between virt-who and each virtualization manager or hypervisor:
- VMware vCenter: TCP port 443
- Microsoft Hyper-V: TCP port 5985
- Red Hat Enterprise Virtualization Manager 3.0 and earlier: TCP port 8443
- Red Hat Enterprise Virtualization Manager 3.1 and later: TCP port 443
- Red Hat OpenStack Platform compute node: depending on a transport type, default is TCP port 22 for SSH communication
  The virt-who connection to local Red Hat OpenStack Platform compute node and local Red Hat Enterprise Linux hypervisor uses local connections and does not need open ports.

2.2.3. Subscriptions

You must have one host-based subscription for each hypervisor in each organization. Subscriptions cannot be shared between organizations.

For more details, see Section 1.2, “Choosing a Subscription”.