+++ This bug was initially created as a clone of Bug #837154 +++ Description of problem: SAM supports different hypervisors to be registered to SAM. It should be display what is the type and version of the host. e.g, if the host is ESX, pls display the type and version like this: ESX 5.0; if the host is kvm, pls display the type and version like this: kvm 0.12.1.2-2.295.el6.x86_64. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from tomckay on 2012-08-27 15:50:37 EDT --- Does the hypervisor type come up with the system facts? If you could print out system facts, that would be helpful. If it's not in the facts, this BZ will need to be cloned to subscription-manager and/or virt-who
Aligning to rhel 6.4. this will be hypervisor as reported by virt-what.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Since we are unable to provide this feature at this time, it has been proposed for the next release of Red Hat Enterprise Linux.
I believe this is the hypervisor which virt-who reports when registering the machine. Tom, is that correct?
This is partially implemented in virt-who right now, except only for libvirt (qemu/kvm). It is fully implemented in candlepin, the hypervisor type is stored in each GuestId objects attributes, rather than a consumers facts. A consumer may be running multiple hypervisors, and if it has zero guests, it's not necessarily a hypervisor, is it? I think we can consider this finished on the candlepin side unless there's some reason the data must be stored in the facts.
Added this feature with guest counting. commit cbaf65c137645889df36baf371512fa2f68a4565 Author: ckozak <ckozak> Date: Thu Sep 12 14:47:12 2013 -0400 Add guest_limit attribute to compliance guest_limit is a new global attribute type, its compliance may depend upon any or all other subscriptions on the system. The highest attached guest_limit (or -1, which is unlimited) is applied to every subscription with a guest_limit. Added a "guest_limit" candlepin capability
candlepin and virt-who feature
In the side of "virt-who", It only has been fixed on libvirt(qemu/kvm) Version-Release number of selected component (if applicable): subscription-manager-1.10.10-1.el7.x86_64 python-rhsm-1.10.10-1.el7.x86_64 virt-who-0.8-12.el7.noarch katello-headpin-1.4.3.23-1.el6sam_splice.noarch candlepin-0.8.26.0-1.el6sam.noarch Steps to verify : RHEL-7.0-20140116.1-Server-x86_64(KVM) against SAM-1.3.1-RHEL-6-20131219.1 Test steps: 1. Configure virt-who run at the libvirt mode #vim /etc/sysconfig/virt-who VIRTWHO_DEBUG=1 VIRTWHO_INTERVAL=10 2. Register host and guest to SAM server 3. Check the virt-who log in the /etc/rhsm/rhsm.log 2014-01-17 16:39:18,915 [DEBUG] @virt.py:66 - Virtual machine found: 7.0_Server_x86_64: e29811e2-cbba-7f38-ec26-9e71d427ac7e 2014-01-17 16:39:18,916 [DEBUG] @subscriptionmanager.py:101 - Sending list of uuids: [{'guestId': 'e29811e2-cbba-7f38-ec26-9e71d427ac7e', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}] Result: The hypervisorType has been report in the virt-who log. it's correct. In the side of candlepin, I'm not very sure whether it has been fixed or not as the SAM server hasn't been updated recently. The latest SAM version is SAM-1.3.1-RHEL-6-20131219.1 However, 1 when I test the ESX mode, check the guest's hypervisor type is "vmware" in the SAM web UI, Please check the attachment "guest on the esx.jpeg" 2 When I test the libvirt mode, check the guest's hypervisor type is "KVM" in the SAM web UI, Please check the attchment "guest on the KVM.jpeg" Can I verify this bug in the part of candepin according to the two above phenomenon? If not, would you mind to tell me how to verify this bug in the part of candepin?
Created attachment 853049 [details] guest on the esx
Created attachment 853050 [details] guest on the KVM
hi, Carter I have verified this bug on the side of virt-who(only for libvirt (qemu/kvm) mode), but on the side of candlepin, Can I verify it according to the comment9's description?
Yep, if the new virt-who is being used, you can query individual guestid objects /consumers/<uuid>/guestids/<guest_id> to get the list of attributes (they are hidden when you get a list of guestids). The attributes contain the vm state, hypervisor type etc for libvirt hypervisors. Let me know if there's any other info you need.
hi, carter Thanks for your quickly reply. I have test it again as your suggestion, but I can't get the guest's attributes. Is that anything wrong with my test process? Could you help me to check it? Version-Release number of selected component (if applicable): subscription-manager-1.10.10-1.el7.x86_64 virt-who-0.8-12.el7.noarch Precondition: SAM ip: 10.66.13.79 username/password: admin/admin virt-who run normally, host and guest have registered to SAM, the host/guest association has been send to SAM. Test process: 1 Check the host's consumer uuid: it's a72d8c40-91cb-402e-a356-6ec9940d9a12 [root@hp-z220-03 xml]# subscription-manager identity system identity: a72d8c40-91cb-402e-a356-6ec9940d9a12 name: hp-z220-03.qe.lab.eng.nay.redhat.com org name: ACME_Corporation org ID: ACME_Corporation 2 Check the guest's guest_id: it's e29811e2-cbba-7f38-ec26-9e71d427ac7e 2014-01-28 11:39:54,790 [DEBUG] @virt.py:66 - Virtual machine found: 7.0_Server_x86_64: e29811e2-cbba-7f38-ec26-9e71d427ac7e 2014-01-28 11:39:54,817 [DEBUG] @subscriptionmanager.py:101 - Sending list of uuids: [{'guestId': 'e29811e2-cbba-7f38-ec26-9e71d427ac7e', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}] 3 Check the guest's attribute in the SAM server. [root@hp-z220-03 xml]# curl -u admin:admin -k https://10.66.13.79/sam/api/consumers/a72d8c40-91cb-402e-a356-6ec9940d9a12/guestids/e29811e2-cbba-7f38-ec26-9e71d427ac7e {"displayMessage":"Resource not found on the server","errors":["Not found"]} Actually Result: It can't get the guest's attribute after step3 Expected Result: It should get the guest's attribute after step3, and the attributes contain the vm state, hypervisor type etc for libvirt hypervisors.
It looks like the call isn't being passed through sam.
According to comment15 , We will check it again after new candlepin come out
hi Carter, It still exist on the latest SAM 1.4. It only be verified on libvirt(qemu/kvm)) against latest Stage candledpin. However, if the host is ESX, it will display attributes is null, please see as the following: [root@hp-z220-03 libvirt-test-API]# curl -u stage_sam_test:redhat -k https://subscription.rhn.stage.redhat.com/subscription/consumers/0d98bc19-fede-4998-aed5-cbcf6e9d4032/guestids/564d0676-800c-ea35-b2f6-982fa056ae84 {"id":"8a99f982467b916101468e16dc70373d","guestId":"564d0676-800c-ea35-b2f6-982fa056ae84","attributes":{},"created":"2014-06-12T03:20:01.000+0000","updated":"2014-06-12T03:20:0 Meanwhile, No matter what host's type is(qemu/kvm or ESX), it can't be verified on the SAM server as it can't get the list of attributes from SAM server , please see as the following: "{"displayMessage":"Resource not found on the server","errors":["Not found"]}" Version-Release number of selected component (if applicable): subscription-manager-1.11.3-5.el5 python-rhsm-1.11.3-3.el5 virt-who-0.9-4.el5 katello-headpin-1.4.3.26-1.el6sam_splice.noarch candlepin-0.9.6-1.el6_5.noarch (In reply to Carter Kozak from comment #15) > It looks like the call isn't being passed through sam.
This BZ dees not belong on the RHEL7.1 tracker: removed reference There is no more work required on the candlepin side -- guestids can carry attributes. It appears that the request is not being correctly routed in SAM which causes the Resource Not Found. virt-who currently only supports reporting hypervisor type data for qemu/kvm. A bug should be filed against virt-who to report the hypervisor type for ESX.
The release of Satellite 5.8 we are deprecating the support of Subscription Asset Manager. The release notes for 5.8 can be found at https://access.redhat.com/documentation/en-us/red_hat_satellite/5.8/pdf/release_notes/Red_Hat_Satellite-5.8-Release_Notes-en-US.pdf. I am therefore closing out this bug as WONTFIX. If you believe this to be an error, please feel free tor each out to either Rich Jerrido or Bryan Kearney. Thank you!