Description of problem: Guest has been ping-pong migrate from Host1 to Host2, Then Unregister the original host(Host1) to the SAM server, The guest's host will replaced by destination host(Host2) in the SAM web UI. Version-Release number of selected component (if applicable): subscription-manager-1.9.9-1.el6.x86_64 python-rhsm-1.9.6-1.el6.x86_64 virt-who-0.8-9.el6.noarch katello-headpin-1.4.3.20-1.el6sam_splice.noarch candlepin-0.8.26-1.el6sam.noarch How reproducible: Always Steps to Reproduce: 1. Prepare two Rhel6.5 hosts(Host1, Host2) and one guest(Guest1) in host1 2. Register Host1, Host2, Guest1 to SAM server 3. Migrate Guest1 from host1 to Host 2 4. Migrate Guest1 back to Host1 5. Unregister Host1 to the SAM server 6. Open SAM web UI(http://samserv.redhat.com/sam), Go to System page, Choose guest1, Go to Detail-->Host & Guest Info, Check the guest's host Actual results: The guest's host is "Host2" Expected results: As the guest's host(Host1) has been unregister to the SAM server, it's host shouldn't be "Host2" but "NULL" in the SAM web UI. Additional info: After step5, Check the Host2's rhsm.log, it can't see the Guest1's virt.uuid, it means the virt-who send the correct data to SAM server.
It has the similar problems after do the following steps: Precondition: In the RHEVM web UI, set the Guest1 run in Specific host: Host1 1. Register Host1, Host2, Guest1 to SAM server 2. Migrate Guest1 from Host1 to Host2, Then migrate back to Host1 3. Then migrate Guest1 to Host2 again 4. Pause the Guest1, Then start Guest, In the RHEVM web UI, it display Guest1's host is Host1. 5. Check the /var/log/rhsm/rhsm.log, Guest1's host is Host1, the host/guest association is correct 6. Open SAM web UI(http://samserv.redhat.com/sam), Go to System page, Choose guest1, Go to Detail-->Host & Guest Info, Check the guest's host Actual results: The Guest1's host is "Host2" in the SAM web UI Expected results: It seems the data hasn't synchronism in the SAM web UI, The Guest1's host should be "Host1"
(In reply to Liushihui from comment #0) > Description of problem: > Guest has been ping-pong migrate from Host1 to Host2, Then Unregister the > original host(Host1) to the SAM server, The guest's host will replaced by > destination host(Host2) in the SAM web UI. > > Version-Release number of selected component (if applicable): > subscription-manager-1.9.9-1.el6.x86_64 > python-rhsm-1.9.6-1.el6.x86_64 > virt-who-0.8-9.el6.noarch > katello-headpin-1.4.3.20-1.el6sam_splice.noarch > candlepin-0.8.26-1.el6sam.noarch > > How reproducible: > Always > > Steps to Reproduce: > 1. Prepare two Rhel6.5 hosts(Host1, Host2) and one guest(Guest1) in host1 > 2. Register Host1, Host2, Guest1 to SAM server > 3. Migrate Guest1 from host1 to Host 2 > 4. Migrate Guest1 back to Host1 > 5. Unregister Host1 to the SAM server > 6. Open SAM web UI(http://samserv.redhat.com/sam), Go to System page, Choose > guest1, Go to Detail-->Host & Guest Info, Check the guest's host > > Actual results: > The guest's host is "Host2" > > Expected results: > As the guest's host(Host1) has been unregister to the SAM server, it's host > shouldn't be "Host2" but "NULL" in the SAM web UI. > > Additional info: > After step5, Check the Host2's rhsm.log, it can't see the Guest1's > virt.uuid, it means the virt-who send the correct data to SAM server. It looks like host1 just hasn't reported that it has guest1 again, I suspect that waiting for virt-who to check in will solve this problem. If that's the case, this is not a bug.
Hi Carter, I think it still should be a bug. Please see following requirement of virt-who: "Check UUIDs after migrate guests. Given a registered RHEL host, install some supportive running guests: e.g RHEL6.2-64, RHEL5.8-32, RHEL6.3-32, RHEL6.3-64. Migrate one guest off the host, then the UUID of the migrated guest should be removed from the virt.uuids list." According to the comment #0's description, As the guest has been migrated off the host1 after step4, and the guest's uuid isn't exist on the host2's virt.uuids list, Therefore, the guest shouldn't exist under the host2 in the SAM web UI. (In reply to Carter Kozak from comment #2) > (In reply to Liushihui from comment #0) > > Description of problem: > > Guest has been ping-pong migrate from Host1 to Host2, Then Unregister the > > original host(Host1) to the SAM server, The guest's host will replaced by > > destination host(Host2) in the SAM web UI. > > > > Version-Release number of selected component (if applicable): > > subscription-manager-1.9.9-1.el6.x86_64 > > python-rhsm-1.9.6-1.el6.x86_64 > > virt-who-0.8-9.el6.noarch > > katello-headpin-1.4.3.20-1.el6sam_splice.noarch > > candlepin-0.8.26-1.el6sam.noarch > > > > How reproducible: > > Always > > > > Steps to Reproduce: > > 1. Prepare two Rhel6.5 hosts(Host1, Host2) and one guest(Guest1) in host1 > > 2. Register Host1, Host2, Guest1 to SAM server > > 3. Migrate Guest1 from host1 to Host 2 > > 4. Migrate Guest1 back to Host1 > > 5. Unregister Host1 to the SAM server > > 6. Open SAM web UI(http://samserv.redhat.com/sam), Go to System page, Choose > > guest1, Go to Detail-->Host & Guest Info, Check the guest's host > > > > Actual results: > > The guest's host is "Host2" > > > > Expected results: > > As the guest's host(Host1) has been unregister to the SAM server, it's host > > shouldn't be "Host2" but "NULL" in the SAM web UI. > > > > Additional info: > > After step5, Check the Host2's rhsm.log, it can't see the Guest1's > > virt.uuid, it means the virt-who send the correct data to SAM server. > > It looks like host1 just hasn't reported that it has guest1 again, I suspect > that waiting for virt-who to check in will solve this problem. > If that's the case, this is not a bug.
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!