Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
RHVH 4.4 gets shipped with RHEL 8.2 + virt-who-0.27.6-1.el8.noarch and this particular version of virt-who does not have any vdsm mode support.
It was removed via https://github.com/candlepin/virt-who/pull/233
~~~
# egrep -rn "libvirt|vdsm" /usr/lib/python3.6/site-packages/virtwho/config.py
53:VW_TYPES = ("libvirt", "esx", "rhevm", "hyperv", "fake", "xen", "kubevirt")
917: self.add_key('type', validation_method=self._validate_virt_type, default='libvirt')
972: if self['type'] == 'libvirt' and 'server' not in self._values:
973: # Owner is not necessary sam an libvirt virt backend
1122: if 'type' in self._values and self._values['type'] in ['libvirt', 'fake']:
1263: 'virt_type': 'libvirt',
1426: # fallback to using libvirt as default virt backend
~~~
As we still refer to https://access.redhat.com/solutions/2025503 , to configure virt-who on top of RHVH, that leads to very undesired results as explained below.
Version-Release number of selected component (if applicable):
virt-who-0.27.6-1.el8.noarch
How reproducible:
always
Steps to Reproduce:
1. Install "virt-who-0.27.6-1.el8.noarch" on any RHEL 8.2 host.
2. Configure a vdsm mode virt-who as displayed below.
~~~
# cat /etc/virt-who.d/test.conf
[vdsm-config]
type=vdsm
hypervisor_id=hostname
~~~
3. Run "systemctl stop virt-who && virt-who -od"
Actual results:
* It does not says anything about unavailable vdsm type but instead marks every single entry in the configuration as "Unknown Option".
~~~
# virt-who -od -c /etc/virt-who.d/test.conf
2020-09-08 15:13:36,408 [virtwho.rhsm_log INFO] MainProcess(1104429):MainThread @config.py:init_config:1523 - Using configuration passed in by -c/--configs; ignoring configuration files in '/etc/virt-who.d/'
2020-09-08 15:13:36,409 [virtwho.rhsm_log DEBUG] MainProcess(1104429):MainThread @config.py:init_config:1562 - [global]: Value for "print_" not set, using default: False
2020-09-08 15:13:36,409 [virtwho.rhsm_log DEBUG] MainProcess(1104429):MainThread @config.py:init_config:1562 - [global]: Value for "log_per_config" not set, using default: False
2020-09-08 15:13:36,409 [virtwho.rhsm_log DEBUG] MainProcess(1104429):MainThread @config.py:init_config:1562 - [global]: Value for "reporter_id" not set, using default: rhel8.example.com-ab62b3d967f64e67a61ba5bc9bcf7f2e
2020-09-08 15:13:36,409 [virtwho.rhsm_log DEBUG] MainProcess(1104429):MainThread @config.py:init_config:1562 - [global]: Value for "interval" not set, using default: 3600
2020-09-08 15:13:36,409 [virtwho.rhsm_log DEBUG] MainProcess(1104429):MainThread @config.py:init_config:1562 - [global]: Value for "log_file" not set, using default: rhsm.log
2020-09-08 15:13:36,409 [virtwho.rhsm_log DEBUG] MainProcess(1104429):MainThread @config.py:init_config:1562 - [global]: Value for "log_dir" not set, using default: /var/log/rhsm
2020-09-08 15:13:36,409 [virtwho.rhsm_log WARNING] MainProcess(1104429):MainThread @config.py:init_config:1562 - [vdsm-config]: Ignoring unknown configuration option "type"
2020-09-08 15:13:36,409 [virtwho.rhsm_log WARNING] MainProcess(1104429):MainThread @config.py:init_config:1562 - [vdsm-config]: Ignoring unknown configuration option "hypervisor_id"
2020-09-08 15:13:36,409 [virtwho.rhsm_log WARNING] MainProcess(1104429):MainThread @config.py:init_config:1562 - Dropping invalid configuration "vdsm-config"
2020-09-08 15:13:36,409 [virtwho.rhsm_log WARNING] MainProcess(1104429):MainThread @config.py:init_config:1562 - No valid configurations found
2020-09-08 15:13:36,409 [virtwho.rhsm_log ERROR] MainProcess(1104429):MainThread @main.py:main:143 - virt-who can't be started: no valid configuration found
~~~
Expected results:
* If someone have by mistakenly created the virt-who is vdsm mode or any other unsupported mode, then in the next virt-who run, it should show this kind of messages which should be clear to understand.
~~
vdsm is not a supported type to use anymore. Please try using any of these available types --> libvirt, esx, rhevm, hyperv, fake, xen, kubevirt
~~
Additional info:
1. The VDSM mode support was removed on the mentioned version via https://github.com/candlepin/virt-who/pull/233 but I don't see any documentation what so ever that points out this fact for user reference.
2. If I use the same configuration from "reproducer steps" and just remove the "type" or set it as "type=libvirt" the virt-who operation works just fine.
3. I will update https://access.redhat.com/solutions/2025503 but the behavior should be fixed and the fact about removal of vdsm support should be present somewhere in user facing documentation apart from the solution article I have mentioned.