Chapter 2. Virt-who Installation and Configuration Overview
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.
184.108.40.206. 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”.
220.127.116.11.1. Red Hat Enterprise Virtualization (version 3.6 and earlier)
Red Hat Enterprise Virtualization (version 3.6 and earlier) includes three types of hypervisors:
- Red Hat Enterprise Virtualization Hypervisor (RHEV-H)
This is a minimal operating system based on Red Hat Enterprise Linux. File system access and root access are limited. Updates via
yumare not possible.
- Red Hat Virtualization Host (RHVH)
- Like RHEV-H, this is a minimal operating system based on Red Hat Enterprise Linux 7. It is distributed as an ISO file from the Customer Portal and contains only the packages required for the machine to act as a host. This is the latest thin host available for Red Hat Enterprise Virtualization. Yum is enabled.
- Red Hat Enterprise Linux host (RHEL-based host)
- This is a Red Hat Enterprise Linux host which has specific software repositories enabled, and has the hypervisor packages installed.
18.104.22.168.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
virt-whoinstalled by default. This type of hypervisor should be registered to Satellite Server.
- Red Hat Enterprise Linux host (RHEL-based host)
- This is a Red Hat Enterprise Linux host which has specific software repositories enabled, and has the hypervisor packages installed. This type of hypervisor is equivalent to the RHEL-based 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.
22.214.171.124. Only RHEV-H
If you have RHEV-H hypervisors, install virt-who on either the Satellite or a dedicated instance of Red Hat Enterprise Linux.
126.96.36.199. Only RHVH
If you have RHVH hypervisors, install virt-who on each RHVH hypervisor and register the hypervisor to Satellite Server.
188.8.131.52. Only RHEL-based host
If you have RHEL-based hypervisors, install virt-who on each RHEL-based hypervisor and register the hypervisor to Satellite Server.
184.108.40.206. 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-based host, and RHEV-H hypervisors in your environment.
- If the number of RHVH and RHEL-based 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-based hypervisors, exclude all RHVH and RHEL-based hypervisors.
For details on how to exclude specific hypervisors, see Section 2.1.5, “Filtering the Scope of virt-who Access”.
2.1.5. Filtering the 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.
220.127.116.11. 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.
18.104.22.168. 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.
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.
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.
An account with read-only access to Red Hat Virtualization Manager is not sufficient. To access Red Hat Virtualization hypervisor information through virt-who, you must create a new role in the Red Hat Virtualization environment with the Admin account type and only Login Permissions enabled 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.
Install the Satellite Server’s CA certificate:
# rpm -ivh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
Register the Red Hat Enterprise Linux server to the Satellite Server:
# 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.
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”.