VIRT-WHO-CONFIG(5)

πŸ“¦ version 1.32.1, in centos-stream 10, centos-stream 9, fedora 43, fedora 44

πŸ’– NAME πŸ’–

virt-who-config β€” the configuration for virt-who, bestie ✨


🌸 SYNOPISIS 🌸

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

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so the config format is ini-like, and it lives in two places: /etc/virt-who.conf and /etc/virt-who.d/*.conf. πŸ’…

The files chillin' in /etc/virt-who.d/*.conf are called virtualization backend configurations. Every non-hidden file in that directory that ends in .conf counts as a configuration file, no cap. And listen β€” if there's no section in a config file (that's the name in square brackets, bestie), then that file just gets ignored and a warning gets shown. πŸ™ˆ

The config at /etc/virt-who.conf is the main configuration for virt-who β€” that's the main character right there. πŸ‘‘

Down below is the whole rundown of both the required and the optional options for both kinds of configs, and how they actually get used. πŸŽ€


✨ GENERAL CONFIGURATION ✨

The general configuration file (it lives at /etc/virt-who.conf) has three special sections: global, defaults, and system_environment. πŸ’–

The settings you can put in defaults are literally any setting listed in the VIRTUALIZATION BACKEND CONFIGURATION section of this manual, and they get applied as defaults to the configurations found in /etc/virt-who.d/*.conf. so handy.

The settings in global affect the overall operation of the application β€” the whole vibe check of the app, fr fr. The following are options that can be specified in the global section:

  • interval β€” how often to check connected hypervisors for changes (in seconds). It also affects how often a mapping is reported. ⏰
  • reporter_id β€” the id of this virt-who instance, and it gets reported with all the mappings. Defaults to HOSTNAME-MACHINEID. πŸͺͺ
  • debug β€” enable debugging output πŸ›
  • oneshot β€” send the list of guest IDs and exit immediately. bye bestie πŸ‘‹
  • log_per_config β€” write a separate log file per configuration in the config directory πŸ“
  • log_dir β€” the absolute path of the directory to write logs to πŸ“‚
  • log_file β€” the file name to write logs to (used only if log_per_config=False) πŸ“
  • configs β€” a list of files containing configurations for virt-who. Used to specify locations other than the default πŸ—ΊοΈ

The settings in system_environment get 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:

  • HTTPS_PROXY β€” proxy hostname for all https requests πŸ”’
  • HTTP_PROXY β€” proxy hostname for all http requests 🌐
  • NO_PROXY β€” 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. πŸ“–

The only required key is type, and it has to be one of the allowed virtualization backend names: ahv, libvirt, esx, hyperv, fake, or kubevirt. periodt. πŸ’…

Please note that special characters must not be escaped. ⚠️

Other options that can be supplied are:

  • server β€” hostname, IP address or URL of the server that provides virtualization information (not applicable for kubevirt mode). πŸ–₯️
  • username β€” username for authentication to the server (not applicable for kubevirt mode). May include a domain. Do not escape the backslash between domain and username. πŸ™…
  • password β€” password for authentication to the server (not applicable for kubevirt mode). πŸ”‘
  • encrypted_password β€” alternative to the password option, an encrypted password that is generated by the virt-who-password(8) utility. πŸ”
  • owner β€” owner for use with Subscription Asset Manager, the Red Hat Customer Portal, or Satellite 6 (not applicable for Satellite 5). πŸ‘€
  • rhsm_username β€” 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) 🎫
  • rhsm_password β€” 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) 🎫
  • rhsm_encrypted_password β€” alternative to the rhsm_password option, an encrypted password that is generated by the virt-who-password(8) utility. πŸ”
  • rhsm_hostname β€” 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. 🏠
  • rhsm_port β€” 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. πŸšͺ
  • rhsm_prefix β€” 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. 🏷️
  • rhsm_proxy_hostname β€” 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. 🌐
  • rhsm_proxy_port β€” 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. πŸ”Œ
  • rhsm_proxy_user β€” 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. πŸ™‹
  • rhsm_proxy_password β€” 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. 🀫
  • rhsm_encrypted_proxy_password β€” alternative to the rhsm_proxy_password option; an encrypted password generated by the virt-who-password(8) utility. πŸ”
  • rhsm_no_proxy β€” 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. 🚫
  • rhsm_insecure β€” 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 the insecure value defined in the system's rhsm.conf. 😬
  • sat_server β€” hostname, IP address or URL of the Satellite 5 server. πŸ›°οΈ
  • sat_username β€” username for authentication to the Satellite 5 server. πŸ™‹
  • sat_password β€” password for authentication to the Satellite 5 server. πŸ”‘
  • sat_encrypted_password β€” alternative to the sat_password option, an encrypted password that is generated by the virt-who-password(8) utility. πŸ”
  • filter_hosts β€” only hosts whose uuid (or hostname or hwuuid, based on hypervisor_id) is specified in the comma-separated list in this option will be reported. Wildcards and regular expressions are supported. Put the value into double-quotes if it contains special characters (like comma). filter_host_uuids is a deprecated alias for this option. 🧲
  • exclude_hosts β€” hosts whose uuid (or hostname or hwuuid, based on hypervisor_id) is specified in the comma-separated list in this option will NOT be reported. Wildcards and regular expressions are supported. Put the value into double-quotes if it contains special characters (like comma). exclude_host_uuids is a deprecated alias for this option. πŸ™…
  • filter_type β€” when this property is not set, then virt-who tries to detect wildcards or a regular expression in the value of filter_hosts or exclude_hosts. This option allows you to specify usage of a regular expression (value 'regex') or wildcards (value 'wildcards'). πŸ”
  • hypervisor_id β€” the property that should be used as identification of the hypervisor. Can be one of the 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 the 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 the kubevirt option. ☸️
  • #kubeversion β€” API version used to override the kubevirt api version fetched from the cluster. Used by the 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 πŸ’…

So like, every backend has its own lil special sauce. Here's the tea, per backend. πŸ«–


✨ ESX BACKEND ✨

  • filter_host_parents β€” only the hosts whose cluster ID shows up in this comma-separated list get reported, everyone else is on read. If the name has special characters in it (commas, we're looking at you bestie 😭), wrap it in double-quotes. Wanna find those cluster IDs in VMware? Run this PowerCLI command: Get-Cluster β€œClusterName” | Select ID
  • exclude_host_parents β€” the inverse vibe: hosts whose cluster ID is in this comma-separated list will NOT be reported. Same deal with special characters, put the name in double-quotes if it's got any. And same PowerCLI command to hunt down the domain names in VMware: Get-Cluster β€œClusterName” | Select ID
  • simplified_vim β€” by default virt-who uses a stripped-down version of the vimService.wsdl file that holds the vSphere SOAP API definition. Set this option to false and it'll use the server-provided wsdl file instead, which gets retrieved automatically. slay, automatic. ✨

🌸 NUTANIX BACKEND 🌸

  • prism_central β€” set literally any value here and the application switches over to Version 3 communication with the AHV API. That's it, that's the whole option. iconic, honestly. πŸ’–

πŸ¦‹ KUBEVIRT BACKEND πŸ¦‹

Okay so the Kubevirt backend runs off a Kubernetes configuration file β€” that file is where the cluster connection details and an authentication token live. You do not need to hand it a hostname or user credentials. Periodt. πŸ™…β€β™€οΈ

But bestie, before you use that kubeconfig file, please make sure you're logged into the cluster so the token actually gets written into the file. To log in you run:

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

πŸŽ€ FAKE BACKEND πŸŽ€

The fake backend pulls host/guests associations straight off a file on disk. Like so:

[fake-virt]
type=fake
file=/path/to/json
is_hypervisor=True
  • type β€” has to be fake always. No negotiation. πŸ’€
  • is_hypervisor β€” if true (which is the default), this option means the fake data gets fetched from a multihost environment. πŸ‘‘
  • file β€” the absolute path to the JSON file, and it's gotta have the same structure as the file that comes back from the virt-who --print command. Example time:
{
    "hypervisors": [
        {
            "uuid": "7e98b6ea-0af1-4afa-b846-919549bb0fe2",
            "guests": [
                {
                    "guestId": "8ae19f08-2605-b476-d42e-4bd5a39f466c",
                    "state": 1
                },
                ...
            ]
        },
        ...
    ]
}

πŸ”„ CONFIGURATION MIGRATION πŸ”„

So back in the day, previous versions of virt-who had extra ways to do config, and now we're cleaning house:

  • 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. Rude? Maybe. Necessary? Yes. 😌

But because nobody wants to lose a config that was working perfectly fine, a migration script got added. That script takes the known system environment variables [VIRTWHO_INTERVAL, VIRTWHO_DEBUG, VIRTWHO_ONESHOT] plus the entries in the service environment file, and folds them all into the general configuration file. The known variables land in the global section, while anything else in the service environment file [i.e. HTTPS_PROXY] lands in the system_environment section. Heads up: this migration can totally result in multiple entries for one specific field. it's giving duplicates, but make it intentional. πŸ™ˆ

Every new entry in the general configuration file shows up after a comment saying it was migrated, so you always know what came from where. The service environment file gets deleted after its entries are migrated β€” but the known system environment variables need to be manually removed by you, or they'll get migrated again if the script is rerun. And nope, those variables won't be recognized by virt-who even if they stick around. delete them, bestie, I'm begging. 😭

The migration script runs automatically when a new RPM is installed, but you can also 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 πŸ’œ


and that's the whole page, bestie!! πŸŽ‰ This one's from the virt-who crew, dated October 2015, and it lives at VIRT-WHO-CONFIG(5) β€” go forth and configure responsibly, you absolute icon πŸ’…βœ¨πŸ«Ά

πŸ“¦ where this page comes from