2. EL 9
  3. virt-who
  4. virt-who-config(5)

Scroll to navigation

VIRT-WHO-CONFIG(5) File Formats Manual VIRT-WHO-CONFIG(5)

NAME

virt-who-config - configuration for virt-who

SYNOPISIS

/etc/virt-who.conf /etc/virt-who.d/*.conf

DESCRIPTION

Configuration format is ini-like for files /etc/virt-who.conf and /etc/virt-who.d/*.conf. The configuration files located at /etc/virt-who.d/*.conf are called virtualization backend configurations. All non-hidden files in this directory (ending in '.conf') are considered configuration files. If no section (name in square brackets) is present in the configuration file, it will be ignored and warning will be shown. The configuration located at /etc/virt-who.conf is the main configuration for virt-who. Below are descriptions of both the required and optional options for both kinds of configs and how they are used.

GENERAL CONFIGURATION

The general configuration file (located at /etc/virt-who.conf), has three special sections global, defaults, and system_environment. The settings that can be specified in defaults are any setting listed in the VIRTUALIZATION BACKEND CONFIGURATION section of this manual. These settings are applied as defaults to the configurations found in /etc/virt-who.d/*.conf.

The settings in the global affect the overall operation of the application. The following are options that can be specified in the global section:

how often to check connected hypervisors for changes (seconds). Also affects how often a mapping is reported.
The id of this virt-who instance, reported with all mappings. Defaults to HOSTNAME-MACHINEID
Enable debugging output
Send the list of guest IDs and exit immediately
Write a separate log file per configuration in the config directory
The absolute path of the directory to write logs to.
The file name to write logs to (used only if log_per_config=False)
A list of files containing configurations for virt-who Used to specify locations other than default

The settings in the system_environment are written to the system's environment and are available for the duration of the process execution. Example options that can be specified in the system_environment section:

Proxy hostname for all https requests
Proxy hostname for all http requests
A comma-separated list of hostnames or domains or ip addresses to ignore proxy settings for. Optionally this may be set to '*' to bypass proxy settings for all hostnames domains or ip addresses.

VIRTUALIZATION BACKEND CONFIGURATION

Each section (or group), denoted by an arbitrary name for the configuration (in square brackets), is read in

Only required key is type that has to have one of the allowed virtualization backend names: ahv, libvirt, esx, hyperv, fake, or kubevirt.

Please note that special characters must not be escaped.

Other options that can be supplied are:

Hostname, IP address or URL of the server that provides virtualization information (not applicable for kubevirt mode).
Username for authentication to the server (not applicable for kubevirt mode). May include domain. Do not escape the backslash between domain and username.
Password for authentication to the server (not applicable for kubevirt mode).
Alternative to the password option, encrypted password that is generated by virt-who-password(8) utility.
Owner for use with Subscription Asset Manager, the Red Hat Customer Portal, or Satellite 6 (not applicable for Satellite 5)
Optional username to use to communicate with Subscription Asset Manager or Satellite 6 instead of the registered system's identity certificate. (not applicable for Satellite 5)
Optional password to use to communicate with Subscription Asset Manager or Satellite 6 instead of the registered system's identity certificate. (not applicable for Satellite 5)
Alternative to the rhsm_password option, encrypted password that is generated by virt-who-password(8) utility.
Optional hostname of the Subscription Asset Manager or Satellite 6 server to use in place of the host defined in the system's rhsm.conf.
Optional port for the Subscription Asset Manager or Satellite 6 server to use in place of the port defined in the system's rhsm.conf.
Optional prefix for the Subscription Asset Manager or Satellite 6 server to use in place of the prefix defined in the system's rhsm.conf.
Optional proxy host name for the Subscription Asset Manager or Satellite 6 server to use in place of the proxy host name defined in the system's rhsm.conf.
Optional proxy port for the Subscription Asset Manager or Satellite 6 server to use in place of the proxy port defined in the system's rhsm.conf.
Optional proxy username for the Subscription Asset Manager or Satellite 6 server to use in place of the proxy username defined in the system's rhsm.conf.
Optional proxy password for the Subscription Asset Manager or Satellite 6 server to use in place of the proxy password defined in the system's rhsm.conf.
Alternative to the rhsm_proxy_password option; encrypted password generated by the virt-who-password(8) utility.
Optional proxy settings for the Subscription Asset Manager or Satellite 6 server to use in place of the no proxy filter defined in the system's rhsm.conf.
Optional boolean to eliminate the validation of tls certificates during connection to the Subscription Asset Manager or Satellite 6 server to use in place of insecure value defined in the system's rhsm.conf.
Hostname, IP address or URL of the Satellite 5 server.
Username for authentication to the Satellite 5 server.
Password for authentication to the Satellite 5 server.
Alternative to sat_password option, encrypted password that is generated by virt-who-password(8) utility.
Only hosts which uuid (or hostname or hwuuid, based on hypervisor_id) is specified in comma-separated list in this option will be reported. Wildcards and regular expressions are supported. Put the value into the double-quotes if it contains special characters (like comma). filter_host_uuids is deprecated alias for this option.
Hosts which uuid (or hostname or hwuuid, based on hypervisor_id) is specified in comma-separated list in this option will NOT be reported. Wildcards and regular expressions are supported. Put the value into the double-quotes if it contains special characters (like comma). exclude_host_uuids is deprecated alias for this option.
When this property is not set, then virt-who tries to detect wildcards or regular expression in value of filter_hosts or exclude_hosts. This option allows to specify usage of regular expression (value 'regex') or wildcards (value 'wildcards').
Property that should be used as identification of the hypervisor. Can be one of following: uuid, hostname, hwuuid. Note that some virtualization backends don't have all of them implemented. Default is uuid. hwuuid is applicable to esx only. This property is meant to be set up before initial run of virt-who. Changing it later will result in duplicated entries in the subscription manager.
#kubeconfig
Path to Kubernetes configuration file which contains authentication and connection details. Used by kubevirt option
#kubeversion
API version used to override kubevirt api version fetched from the cluster. Used by kubevirt option
#insecure
Eliminate validation of tls certificates during connection to kubevirt

EXAMPLE

[test-esx]
type=esx
server=1.2.3.4
username=admin
password=password
owner=test
rhsm_username=admin
rhsm_password=password

BACKEND SPECIFIC OPTIONS

ESX BACKEND

Only hosts which cluster ID is specified in comma-separated list in this option will be reported. Put the name into the double-quotes if it contains special characters (like comma). PowerCLI command to find the domain names in VMware `Get-Cluster “ClusterName” | Select ID`
Exclude hosts which cluster ID is specified in comma-separated list in this option will NOT be reported. Put the name into the double-quotes if it contains special characters (like comma). PowerCLI command to find the domain names in VMware `Get-Cluster “ClusterName” | Select ID`
virt-who by default uses stripped-down version of vimService.wsdl file that contains vSphere SOAP API definition. Set this option to false to use server provided wsdl file that will be retrieved automatically.

NUTANIX BACKEND

Any value set for this parameter will cause the application to use Version 3 communication with the AHV API

KUBEVIRT BACKEND

Kubevirt backend uses a Kubernetes configuration file where there are cluster connection details and an authentication token. There is no need to provide a hostname nor user credentials. Before using the kubeconfig file please make sure to login to the cluster so the token is written to the file. To login you need to run:

oc login --username=myuser --password=mypass

FAKE BACKEND

Fake backend reads host/guests associations from the file on disk, for example:

[fake-virt]
type=fake
file=/path/to/json
is_hypervisor=True

Must be always fake.

If true (default), the option determines that the fake data are fetched from multihost environment.

Absolute path to the JSON file that has the same structure as file returned from virt-who --print command, for example:
{
"hypervisors": [
{
"uuid": "7e98b6ea-0af1-4afa-b846-919549bb0fe2",
"guests": [
{
"guestId": "8ae19f08-2605-b476-d42e-4bd5a39f466c",
"state": 1
},
...
]
},
...
]
}

CONFIGURATION MIGRATION

Previous versions of virt-who employed additional means of configuration:

Setting of environment variables [set in the user's profile script or in the default global profile]
A service environment file [/etc/sysconfig/virt-who]

The new version of virt-who no longer supports setting most options via the environment. In order to not lose previously valid configurations that made use of environment variables, a migration script has been added. That script will incorporate the known system environment variables [VIRTWHO_INTERVAL, VIRTWHO_DEBUG, VIRTWHO_ONESHOT] and the entries in the service environment file into the general configuration file. The known variables will land in the global section while any others in the service environment file [i.e. HTTPS_PROXY] will land in the system_environment section. This migration may result in multiple entries for a specific field.

Each new entry in the general configuration file will come after a comment indicating that it was migrated. The service environment file will be deleted after its entries are migrated, but the known system environment variables will need to be manually removed or they will be migrated again if the script is rerun. Those variables will not be recognized by virt-who even if they remain.

The migration script will be run when a new RPM is installed, but you can run it manually with python after the RPM is installed:

[python_sitelib]/virtwho/migrate/migrateconfiguration.py

AUTHOR

Radek Novacek <rnovacek at redhat dot com>
William Poteat <wpoteat at redhat dot com>

SEE ALSO

virt-who(8), virt-who-password(8)

October 2015 virt-who