Hide Forgot
Description of problem: If virt-who has send remote hypervisor and local host to satellite, guest can't move back to local host util there is updating on host/guest mapping. Version-Release number of selected component (if applicable): virt-who-0.17-10.el7.noarch subscription-manager-1.17.11-1.el7.x86_64 python-rhsm-1.17.7-1.el7.x86_64 How reproducible: Always Steps to Reproduce: Preconditon: There are two hosts(host1, host2) and a guest on host1, host1 run at local libvirt mode, host2 run at remote libvirt mode to monitor host1 1. Register host1, host2,guest to satellite6. 2. Host1: Configure host1 run at local libvirt mode and restart virt-who, virt-who send host/guest mapping info to satellite [root@hp-z220-06 ~]# cat /etc/sysconfig/virt-who | grep -v ^# | grep -v ^$ VIRTWHO_DEBUG=1 3. In satellite webUI, go to Hosts-->Content hosts-->guest-->Detail, it will show guest's Virtual Host is local host1(local host), see attachment local_host.jpeg 4. Host2: Configure host2 run at remote libvirt mode to monitor host1 and restart virt-who, virt-who send host/guest mapping info to satllite [root@hp-z220-08 virt-who.d]# cat /etc/virt-who.d/virt [test-libvirt] type=libvirt server=qemu+ssh://10.66.144.4/system username=root password=qwer1234P! owner=ACME_Corporation env=Library [root@hp-z220-08 virt-who.d]# service virt-who restart 5. In satellite webUI, go to Hosts-->Content hosts-->guest-->Detail, it will show guest's Virtual Host is remote hypervisor1(virt-who-9748e300-28ee-11e2-b631-10604b5b24e2-1), see attachment remote_host.jpeg 6. Host2: Stop virt-who service on host2. [root@hp-z220-08 virt-who.d]# service virt-who stop Redirecting to /bin/systemctl stop virt-who.service 7. Host1: Restart virt-who service on host1 and check virt-who's log, virt-who send correct local host/guest mapping to satellite. [root@hp-z220-06 ~]# service virt-who restart Redirecting to /bin/systemctl restart virt-who.service 8. In satellite webUI, go to Hosts-->Content hosts-->guest-->Detail, check guest's Virtual Host. Actual results: It still show guest's Virtual Host is remote host1(remote hypervisor), see attachment remote_host.jpeg Expected results: The guest's Virtual Host should move back to local host1 since virt-who has send local host1/guest mapping to satellite again and remote hypervisor/guest reporting has been stopped. Additional info: In the step7, if there is host/guest mapping info updating(stop/start/pause guest), virt-who can show correct host under guest's Virtual Host.
Does virt-who send correct information? If so, this bug should be assigned to Satellite. I'm also missing mentioned attachments.
Created attachment 1198126 [details] local_host.jpeg
Created attachment 1198127 [details] remote_host
Sorry for missing attachment, I have uploaded it to bugzilla just now. Thanks for kindly remind. Yes, virt-who send correct mapping info to satellite, but satellite webUI show wrong virtual host. I'll reassign it to satellite. BTW: Satellite version: Satellite-6.2.0-RHEL-7-20160831.0
It has the same problem when virt-who against stage candlepin.
I think this is likely a candlepin issue. It sounds like candlepin is returning the first hypervisor it finds rather than the newest hypervisor it finds. Satellite is calling "/candlepin/consumers/UUID/host/" to get the hots for the given guest. Would you agree bcourt?
Candlepin is searching for the host that had the most recent guest report for the guest consumer. (https://github.com/candlepin/candlepin/blob/candlepin-0.9.54-HOTFIX/server/src/main/java/org/candlepin/model/ConsumerCurator.java#L515) I'd be a little concerned about mixing local-mode libvirt reports and remote-mode libvirt reports as we have seen issues in the past where different uuids were reported depending on the mode used. I would recommend trying using exclusively remote mode to see if you can reproduce that way first. Are you able to reproduce using libvirt-remote mode exclusively for both hosts?
Check it on latest RHEL-6.9-20161216.1 against satellite6.2.6. The phenomenon as the following: 1. If using libvirt-remote mode exclusively for both hosts to monitor the same host, it hasn't this problem. 2. If using libvirt-remote mode exclusively for both hosts to monitor the other host, it also hasn't this problem. 3. If do it as bug's description, a host using local libvirt mode and the other using remote libvirt mode to monitor the same host, the bug still exist. Therefore, this problem only occurred when mixing local-mode libvirt reports and remote-mode libvirt reports
Mixing libvirt remote and libvirt local back-ends for reporting on a single host/guest does not work due to limitations in the way libvirt reports uuids based on the method used to connect. We do not have a way to normalize this information reliably so can not compensate for it.