Description of problem: Virt-manager searches for the hypervisor packages using the yum backend. If you're downloading a package in the meanwhile, it just loops on searching for available Hypervisors. It should at least inform the user that the yum backend is in use, and it will continue after the current yum operation is finished. Or maybe make the hypervisor check the first time it runs only. Version-Release number of selected component (if applicable): Fedora 16 Beta [root@tardis libvirt]# rpm -q virt-manager virt-manager-0.9.0-6.fc16.noarch How reproducible: Very Steps to Reproduce 1. yum -y upgrade 2. virt-manager Actual results: Hangs on the searching for available hypervisors screen Expected results: Virt-manager connected to the local hypervisor Additional info:
That's expected. Other apps that install things via packagekit will suffer the same problem. Only one app can be talking to yum at a time, so virt-manager has to wait for yum to finish. There isn't any way for us to avoid the delay. Closing as NOTABUG. Please reopen if I'm mistaken
There is a related bug: The search for hypervisors cannot be canceled, therefore it waits forever, if one has "yum shell" open in a different shell. There is a cancel button, but it does not have any effect. Also, there is no indication that it waits for yum, therefore it is unclear what to do if it takes a long time.
I noticed the bug with virt-manager-0.10.0-1.fc19: Reproduce: - yum shell, keep it running - run virt-manager, try to abort hypervisor discovery -> cannot be aborted expected: -> abort works -> virt-manager tells me that it is waiting for yum
As a yum rum can take rather long (I just say a KDE & openoffice update ...) waiting for yum is totally inacceptable. Meanwhile it appears the new version of libvirt-manager in F19 also ate its configuration for all connections but remote hosts. I was previously using F17.
(In reply to Till Maas from comment #2) > > Also, there is no indication that it waits for yum, therefore it is unclear > what to do if it takes a long time. Its true.. It ate my time today and was no clue whats happening. After checking the code I found out the possibility of yum process and things were in control. I am attaching a patch to notify the user about this.
Created attachment 782567 [details] Patch to avoid long wait of end user
(In reply to Till Maas from comment #2) > There is a related bug: > The search for hypervisors cannot be canceled, therefore it waits forever, > if one has "yum shell" open in a different shell. There is a cancel button, > but it does not have any effect. def _on_cancel(self, ignore1=None, ignore2=None): if not self.cancel_cb or not self._is_thread_active(): return self.cancel_cb(*self.cancel_args) //job_canceled is 'false' here: so it will not go ahead with 'Cancelling Job' progress bar. I am not much sure whether below should look like 'if not self.job' instead of 'if self.job_canceled'. -->[1] if self.job_canceled: self._hide_warning() self._set_stage_text(_("Cancelling job..."), canceling=True) //Regardless of the worry about [1], below will 'destroy' the topwindow when we press 'cancel'. I am attaching a patch with below change: Cole can review it though. else: self.topwin.destroy() //Also not sure whether we need to call any cleanup() at this stage.
Created attachment 782573 [details] Patch to respect 'cancel' button ..
(In reply to Humble Chirammal from comment #6) > Created attachment 782567 [details] > Patch to avoid long wait of end user The problem with this is that we are talking to packagekit. packagekit could be talking to some non-yum package managed, like it does on debian. So this isn't acceptable for upstream virt-manager. (In reply to Humble Chirammal from comment #8) > Created attachment 782573 [details] > Patch to respect 'cancel' button .. This isn't acceptable because it's just closing the window and acting like things were cancelled. In reality the packagekit transaction will continue chugging along behind the scenes, so pretending like it was cancelled is disingenuous. I think virt-manager should just drop the custom search dialog and pass everything to PackageKit InstallNames. This will give the standard 'this software requires XXX to function, want to search for it now?' dialog from packagekit which has already solved these problems. The only reason I initially avoided that is because it's not exactly true that we require libvirt-daemon + kvm, but it's what most people want. However if someone doesn't want KVM, they can just click 'cancel' and we will never ask again.
(In reply to Cole Robinson from comment #9) > (In reply to Humble Chirammal from comment #6) > > Created attachment 782567 [details] > > Patch to avoid long wait of end user > > The problem with this is that we are talking to packagekit. packagekit could > be talking to some non-yum package managed, like it does on debian. So this > isn't acceptable for upstream virt-manager. > Hi Cole, Yep, the intention was to notify end user about *a* possibility. But I missed to think about other distros, how-ever we could consider it for downstream . > (In reply to Humble Chirammal from comment #8) > > Created attachment 782573 [details] > > Patch to respect 'cancel' button .. > > This isn't acceptable because it's just closing the window and acting like > things were cancelled. In reality the packagekit transaction will continue > chugging along behind the scenes, so pretending like it was cancelled is > disingenuous. Yes, as mentioned in c#7, I havent tried any clean up jobs there in the patch, so it should be active in bg. > > I think virt-manager should just drop the custom search dialog and pass > everything to PackageKit InstallNames. This will give the standard 'this > software requires XXX to function, want to search for it now?' dialog from > packagekit which has already solved these problems. The only reason I > initially avoided that is because it's not exactly true that we require > libvirt-daemon + kvm, but it's what most people want. However if someone > doesn't want KVM, they can just click 'cancel' and we will never ask again. Sounds like a plan :)
Fixed upstream now commit 280663c685544cb7cfdca3024b357a0b5d9b04c0 Author: Cole Robinson <crobinso> Date: Sun Sep 1 14:19:23 2013 -0400 packageutils: Don't implement our own search dialog (bz #746011)
This is painful to backport to F19, so just moving to F20 where it's fixed in updates-testing
virt-manager-0.10.0-3.gita2e52067.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/virt-manager-0.10.0-3.gita2e52067.fc20
Package virt-manager-0.10.0-3.gita2e52067.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-3.gita2e52067.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17628/virt-manager-0.10.0-3.gita2e52067.fc20 then log in and leave karma (feedback).
virt-manager-0.10.0-3.gita2e52067.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.