Description of problem: rhn-virtualization-host reports incorrect virtualization type of KVM guests to RHN. With advent of KVM-guest entitlements pack, this can have huge impact on the RHN entitlement consumption. Version-Release number of selected component (if applicable): [root@eq4 rhn]# rpm -qa rhn\* rhn-check-0.4.20-9.el5.noarch rhnlib-2.2.7-2.el5.noarch rhn-virtualization-common-5.3.0-4.el5sat.noarch rhn-setup-gnome-0.4.20-9.el5.noarch rhnsd-4.7.0-4.el5.x86_64 rhn-virtualization-host-5.3.0-4.el5sat.noarch rhn-setup-0.4.20-9.el5.noarch rhn-client-tools-0.4.20-9.el5.noarch How reproducible: Always. Steps to Reproduce: 1. Have RHEL 5.4 host with KVM enabled ready and registered to RHN. 2. Create RHEL5.4 KVM guest and register it to RHN. 3. Observe the 'Virtualization Type' in RHN System Details page. 4. Most likely it'll show KVM/QEMU initially (that is correct). 5. Wait until the cronjob rhn/virtualization/poller.py reports info on guest to RHN. 6. Check the 'Virtualization Type' in RHN System Details page. Actual results: "Fully Virtualized" Expected results: "KVM/QEMU" Additional info: This is caused by a bug somewhere in python code of rhn-virtualization-host. The correct virtualization type label of KVM guests which is to be reported to RHN is 'qemu' - all lowercase letters.
While making rhn-profile-sync report 'qemu' instead of 'fully_virtualized' would be neat for RHN Hosted, such a change would break rhn-profile-sync for all machines registered to RHN Satellite (tested!). No version of RHN Satellite currently contains 'qemu' in rhnVirtualInstanceType table and reporting 'qemu' instead of 'fully_virtualized' would result into internal server error during every rhn-profile-sync. Even if we would add 'qemu' as a valid virtualization type into some of the future satellite releases, we still could not change the client code, since it would have to work with older satellites. Mu suggestion for RHN Hosted backend code is: in case KVM guest is registered and recognized as a KVM/QEMU virt. type, all updates coming from rhn-profile-sync trying to convince backend that the guest is 'fully_virtualized' should be ignored and the backend server will trust the original smbios information that was provided during guest registration. Would this be acceptable or is there perhaps other solution for the described problem that I don't see? (a solution that won't break the protocol of course)
(In reply to comment #1) > While making rhn-profile-sync report 'qemu' instead of 'fully_virtualized' > would be neat for RHN Hosted, such a change would break rhn-profile-sync > for all machines registered to RHN Satellite (tested!). > > No version of RHN Satellite currently contains 'qemu' in rhnVirtualInstanceType > table and reporting 'qemu' instead of 'fully_virtualized' would result > into internal server error during every rhn-profile-sync. > > Even if we would add 'qemu' as a valid virtualization type into some of > the future satellite releases, we still could not change the client > code, since it would have to work with older satellites. > > Mu suggestion for RHN Hosted backend code is: in case KVM guest is > registered and recognized as a KVM/QEMU virt. type, all updates coming > from rhn-profile-sync trying to convince backend that the guest is > 'fully_virtualized' should be ignored and the backend server will trust > the original smbios information that was provided during guest registration. > > Would this be acceptable or is there perhaps other solution for > the described problem that I don't see? (a solution that won't break > the protocol of course) As is done for registration, the client could check the server side capabilities to see if it has supports_smbios, which would mean it supports the kvm virt type. If that cabability existed, then the client could send up kvm, otherwise it could revert to the old behaviour.
(In reply to comment #2) > (In reply to comment #1) [...] > As is done for registration, the client could check the server side > capabilities to see if it has supports_smbios, which would mean it supports the > kvm virt type. If that cabability existed, then the client could send up kvm, > otherwise it could revert to the old behaviour. I'm not sure whether I got the above correct: supports_smbios as in the client should check whether server (RHN Hosted / RHN Satellite) features 'registration.smbios' capability and send 'kvm' in case it does, revert to 'fully_virtualized' in case it does not? If so, this won't work: even latest RHN Satellite tells the clients it supports 'registration.smbios' but it will freak out in case the KVM host during rhn-profile-sync says that some of its guests is 'virt_type':'qemu'.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > [...] > > As is done for registration, the client could check the server side > > capabilities to see if it has supports_smbios, which would mean it supports the > > kvm virt type. If that cabability existed, then the client could send up kvm, > > otherwise it could revert to the old behaviour. > > I'm not sure whether I got the above correct: supports_smbios as in > the client should check whether server (RHN Hosted / RHN Satellite) features > 'registration.smbios' capability and send 'kvm' in case it does, revert > to 'fully_virtualized' in case it does not? > > If so, this won't work: even latest RHN Satellite tells the clients it > supports 'registration.smbios' but it will freak out in case the KVM > host during rhn-profile-sync says that some of its guests is > 'virt_type':'qemu'. Ok then, let's add a new server cabability for kvm virt type support.
This is only cosmetic, correct? How hard to fix? Milan.
(In reply to comment #5) > This is only cosmetic, correct? Correct. > How hard to fix? Milan. We'd need a schema change in Satellite (data only), and think of a solution for rhn-virtualization where we'd be able to report 'qemu' to new Satellites and RHN without breaking older Satellites. One of the solution we were discussing (via email) with James Bowes a while ago was new capability on both RHN and Satellite which would indicate to the client that it's safe to report 'qemu' as a a virt. type. Is there perhaps a better / more elegant solution for this?
Moving to sat600-triage and off 5.4, I consider this a low priority change.
*** Bug 675342 has been marked as a duplicate of this bug. ***
*** Bug 823888 has been marked as a duplicate of this bug. ***
We have re-reviewed this bug, as part of an ongoing effort to improve Satellite/Proxy feature and bug updates, review and backlog. We're closing this Bugzilla due to the Satellite 5 version this bug was reported against having been EOL (End-of-Life) [1]. Please re-open if the issue still exists in the latest Satellite 5 version. [1] Satellite Life Cycle page: https://access.redhat.com/support/policy/updates/satellite