Hide Forgot
1. What is the nature and description of the request? --> When configuring virt-who for RHEV or RHEL-OSP hypervisors/compute nodes, the proper configuration of virt-who is complex and complicated by the fact that the user may also register the hypervisor/compute nodes via subscription-manager. This effectively creates multiple consumer records within Candlepin making it difficult to properly attach subscriptions. 2. Why does the customer need this? (List the business requirements here) --> Most subscriptions that are sold for RHV/RHEL-OSP include content for both the hypervisor AND its guests. And since we cannot 'break' a subscriptions components across two host records, the customer ends up in a situation where they do not have enough subscriptions to properly subscribe both hypervisors. 3. How would the customer like to achieve this? (List the functional requirements here) --> There should be only one profile created for RHEV/RHEL OSP hypervisors through which Hypervisor can get updates and guests running on the hypervisor can inherit subscription.
This issue has been remedied in candlepin in version 2.3.5+ The virt-who part was remedied in version 0.22.5+
Related BZ's 1314902, 1410601, 1566000, 1576110
Virt-who supports the request from comment 6. Reassigning to the virt-who configure plugin for us to verify that plugin can generate a config capable of the same.
According to our testing, this issue is already resolved in sat6.6, take vdsm host as the example, the actually result is: if you create a rhevm virtwho-configure file for the vdsm mode, start virt-who service, you will see an entry with 'virt-who-xxx' in the webUI, and then if you run subscription-manager to register the vdsm host again, you will get error message: "HTTP error (422 - Unknown): The DMI UUID of this hos..." So the result is: Always only one entry displayed in the webUI for the same host.
Based upon comment 11, closing this bugzilla as 'nextrelease' as it will be resolved in Satellite 6.6.
*** Bug 1755082 has been marked as a duplicate of this bug. ***