Description of problem: Org admins are not able to view some systems with invalid hypervisor reference Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Log on as affected org admin (ex:ende_tecnologias) 2. View affected system (ex:609bb124-da3c-4555-ba30-e26d330b40c0) 3. Actual results:403 error Permission required Expected results: Able to view system Additional info: This appears to be an issue with these systems pointing to a bad/invalid host system. If you check the system facts for the systems that could not be accessed: 1. They all have a system fact "virt.uuid" 2. All of those "virt.uuid" facts point to a hypervisor that doesn't exist 3. When we lookup these invalid virt.uuids, it can trip a bug on our backend system which causes the backend system to return a real hypervisor, but a hypervisor that isn't owned by the customer 4. Since the (incorrectly returned) hypervisor isn't owned by the customer, he doesn't have permission to view the details about said hypervisor, which means he can't see the page as a result The workaround, until we fix the bug on the backend, is to have the customer update the systems' virt.uuid system facts, so that they point at a correct hypervisor. These are the incorrect values currently associated with each of the systems:
After digging into this a bit more, I realized I wasn't using virt.uuid correctly. In fact, virt.uuid IS (eventually) referencing a valid hypervisor consumer, however that hypervisor consumer is not owned by the same owner of the guest. Thus, the reason that the RHSM Web base for the affected system returns a 403 is because when RHSM Web retrieves the host information with: GET consumers/609bb124-da3c-4555-ba30-e26d330b40c0/host ...the host belongs to a different owner that the user (an org admin) is not a part of. So, the BZ isn't about a non-existent hypervisor. The BZ is really about how guest consumers are allowed to say they are owned by somebody else's hypervisor.
Since this issue is about guest consumers being registered against a different owner's hypervisor, is there a fix/workaround that the customer can do until candlepin disallows guests belonging to a different owner's hypervisors? Like, can a virtwho config change be made so that the guests are pointing to a hypervisor they own? Sidenotes: - In at least one case, the customer had 0 hypervisors registered to their account. I found this weird, as I would have expected if the owner had guest consumers, then the owner should have had at least one hypervisor too, but nope. - In another case, one customer's guests were each double registered, one to a hypervisor they owned, and one to a different owner's hypervisor. - For whatever reason, it it always just one different owner. The guests of one owner could all be hosted by different hypervisors, but all those hypervisors are owned by the one (different) owner.
How does one retrieve the virt-who configuration? What files do they need to provide?
Closing as current release given that 2.3.8 just went live in production yesterday. If you are still seeing this issue please reopen.