Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Version-Release number of selected component (if applicable):
virt-who-0.17-2.el7.noarch
subscription-manager-1.17.6-1.el7.x86_64
python-rhsm-1.17.2-1.el7.x86_64
How reproducible:
always
Steps to Reproduce:
1. prepare a xenserver, and there are two guests installed.
2. configure virt-who for this xenserver
VIRTWHO_XEN=1
VIRTWHO_XEN_OWNER=ACME_Corporation
VIRTWHO_XEN_ENV=Library
VIRTWHO_XEN_SERVER=10.73.5.238
VIRTWHO_XEN_USERNAME=root
VIRTWHO_XEN_PASSWORD=Welcome1
3. register virt-who host to satellite-server-01
4. restart virt-who service and check the mapping info
2016-06-16 05:02:13,623 [virtwho.main DEBUG] MainProcess(710):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: {
"82060dac-669f-4ec2-8d01-f1dff5c73d2e": [
{
"guestId": "03dc7c18-1473-4011-5f85-484702653b89",
"state": 1,
"attributes": {
"active": 1,
"virtWhoType": "xen"
}
},
{
"guestId": "8ac7bb31-9ae2-91f8-b7dd-30a4413a9a8f",
"state": 1,
"attributes": {
"active": 1,
"virtWhoType": "xen"
}
}
]
}
========== two guests fetched ==========
"guestId": "03dc7c18-1473-4011-5f85-484702653b89"
"guestId": "8ac7bb31-9ae2-91f8-b7dd-30a4413a9a8f"
5. register guests to different satellite servers
register guest-01 to satellite-server-01
register guest-02 to satellite-server-02
6. open the two satellite-servers webUI to check the mapping info
guest-01 belongs to hypervisor:82060dac-669f-4ec2-8d01-f1dff5c73d2e
guest-02 belongs to nothing
7. subscribe hypervisor(82060dac-669f-4ec2-8d01-f1dff5c73d2e) to a pool which can generate the virtual pool for guest,
such as "Red Hat Enterprise Linux for Virtual Datacenters, Standard "
8. check the guest virtual pool by "subscription-manager list --available"
guest-01: can list the Datacenter virtual pool
guest-02: also can list the Datacenter virtual pool
Actual results:
guest-02 can list the the Datacenter virtual pool
Expected results:
guest-02 should not list the the Datacenter virtual pool, because there is no any hypervisor associated with guest-02 in satellite-server-02.
Additional info:
Eko, are you sure this is virt-who issue? It seems that this is problem somewhere in Satellite, virt-who just reports host/guest association, it doesn't do anything with pools etc.
Eko,
For steps 6 through 8 please list what you are seeing on each satellite server. I'm not sure from the description what you are seeing on satellite-server-01 and what you are seeing on satellite-server-02.
This is an older bug which I do not envision being addressed in the near term. I am closing this out. If you believe doing so is an issue, please feel free to re-open and provide additional business information. Thank you.
Version-Release number of selected component (if applicable): virt-who-0.17-2.el7.noarch subscription-manager-1.17.6-1.el7.x86_64 python-rhsm-1.17.2-1.el7.x86_64 How reproducible: always Steps to Reproduce: 1. prepare a xenserver, and there are two guests installed. 2. configure virt-who for this xenserver VIRTWHO_XEN=1 VIRTWHO_XEN_OWNER=ACME_Corporation VIRTWHO_XEN_ENV=Library VIRTWHO_XEN_SERVER=10.73.5.238 VIRTWHO_XEN_USERNAME=root VIRTWHO_XEN_PASSWORD=Welcome1 3. register virt-who host to satellite-server-01 4. restart virt-who service and check the mapping info 2016-06-16 05:02:13,623 [virtwho.main DEBUG] MainProcess(710):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: { "82060dac-669f-4ec2-8d01-f1dff5c73d2e": [ { "guestId": "03dc7c18-1473-4011-5f85-484702653b89", "state": 1, "attributes": { "active": 1, "virtWhoType": "xen" } }, { "guestId": "8ac7bb31-9ae2-91f8-b7dd-30a4413a9a8f", "state": 1, "attributes": { "active": 1, "virtWhoType": "xen" } } ] } ========== two guests fetched ========== "guestId": "03dc7c18-1473-4011-5f85-484702653b89" "guestId": "8ac7bb31-9ae2-91f8-b7dd-30a4413a9a8f" 5. register guests to different satellite servers register guest-01 to satellite-server-01 register guest-02 to satellite-server-02 6. open the two satellite-servers webUI to check the mapping info guest-01 belongs to hypervisor:82060dac-669f-4ec2-8d01-f1dff5c73d2e guest-02 belongs to nothing 7. subscribe hypervisor(82060dac-669f-4ec2-8d01-f1dff5c73d2e) to a pool which can generate the virtual pool for guest, such as "Red Hat Enterprise Linux for Virtual Datacenters, Standard " 8. check the guest virtual pool by "subscription-manager list --available" guest-01: can list the Datacenter virtual pool guest-02: also can list the Datacenter virtual pool Actual results: guest-02 can list the the Datacenter virtual pool Expected results: guest-02 should not list the the Datacenter virtual pool, because there is no any hypervisor associated with guest-02 in satellite-server-02. Additional info: