| Summary: | [RFE] Failed to send update info to server since the previous host's uuid has been updated by virt-who | |||
|---|---|---|---|---|
| Product: | [Community] Candlepin | Reporter: | Barnaby Court <bcourt> | |
| Component: | candlepin | Assignee: | candlepin-bugs | |
| Status: | CLOSED DUPLICATE | QA Contact: | Katello QA List <katello-qa-list> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 0.9.54 | CC: | csnyder, dmesser, katello-qa-list, khowell, ldai, redakkan, sgao, shetze, shihliu, skallesh | |
| Target Milestone: | --- | Keywords: | FutureFeature, Triaged | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | 1362724 | |||
| : | 1412719 (view as bug list) | Environment: | ||
| Last Closed: | 2017-07-31 17:42:14 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1362724, 1412719 | |||
|
Description
Barnaby Court
2016-09-29 19:29:00 UTC
Please investigate the use of the virt-who configuration option 'hypervisor_id=hostname'. It seems that this configuration will nearly always break virt-who's mapping on the candlepin back to the right consumer. I can confirm the behavior reported. Initial registration of a RHEV hypervisor will result in UUID v1. Upon first detection of guests on that hypervisor by virt-who the corresponding content-host will change to UUID v2. Subsequent subscription-manager commands on the hypervisor will fail. Also a VDC subscription attached to the hypervisor will become invalid, all guests will loose their entitlement. As such it's not possible to use virt-who with RHEV and consequently Satellite with RHEV. Daniel, Can you please confirm whether using 'hypervisor_id=uuid' fixes the issues? Hi Kevin, I don't have access to the environment anymore but it fixes the issue - however the hypervisors will appear with UUID-based names in Satellite which is less than ideal. Also this differs from the docs. I think we should convert this to an RFE because of the following. The configuration parameter 'hypervisor_id' allows specifying in virt-who what value to use to uniquely identify a particular hypervisor. Allowing this value to be set to something that will change and is not unique (for example, setting the parameter to 'hostname') will cause issues because those properties are expected of the data being reported by virt-who on the server (candlepin) side of hypervisor checkins. As far as I can tell the reason that this value is configurable is because this same value is also used to generate a display name for hypervisor instances. Naturally, traditional UUIDs do not make for very human-friendly display names. What I propose we do is investigate if it is possible to get a UUID value from all supported virtualization frameworks (HyperV, VMWare ESX/vSphere, etc). If we can, we should only use the UUID from all frameworks as the unique hypervisor_id. We should also collect the hostname from all frameworks which support doing so and include this information with all reports from virt-who. In this way we can use the hostname as a display name on the server side while maintaining a unique way for us to refer to a particular hypervisor. We can use this bug to track the work done server side to use the reported hostname as the display name. I'll clone this bug to track the work necessary on the virt-who side. @Chris: I second that proposal. Closing in favor of solution in bug 1410601 (and related). *** This bug has been marked as a duplicate of bug 1410601 *** |