Bug 1285163
| Summary: | Error massage pop up "Unable to connect to libvirt with URI: [none]." continuously when stop libvirtd service | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | mxie <mxie> |
| Component: | virt-viewer | Assignee: | Virt Viewer Maint <virt-viewer-maint> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.8 | CC: | cfergeau, dblechte, fidencio, juzhou, mzhan, rbalakri, tzheng, virt-bugs, virt-viewer-maint, xiaodwan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | virt-viewer-2.0-8.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1246022 | Environment: | |
| Last Closed: | 2016-05-10 21:19:08 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: | |
| Embargoed: | |||
| Bug Depends On: | 1246022 | ||
| Bug Blocks: | |||
|
Comment 2
mxie@redhat.com
2015-11-30 08:09:00 UTC
For the bug1285163 I can reproduce the bug with builds: libvirt-0.10.2-55.el6.x86_64 spice-gtk-0.26-4.el6.x86_64 virt-viewer-2.0-7.el6.x86_64 qemu-kvm-0.12.1.2-2.481.el6.x86_64 usbredir-0.5.1-2.el6.x86_64 Try to verify this bug with builds: libvirt-0.10.2-55.el6.x86_64 spice-gtk-0.26-6.el6.x86_64 virt-viewer-2.0-8.el6.x86_64 qemu-kvm-0.12.1.2-2.481.el6.x86_64 usbredir-0.5.1-3.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Use virt-viewer connect to a shutdown guest. # virsh destroy test Domain test destroyed # virt-viewer test --wait 2. Stop libvirtd service on host. # service libvirtd stop 3. Start libvirtd service on host again. # service libvirtd start Result now: Step1 outputs: You can see "Waiting for guest domain to start" in virt-viewer terminal. Step2 outputs: You can see "Waiting for libvirt to start" in virt-viewer terminal. There is no error dialogue "Unable to connect to libvirt with URI: [none]" pop up any more Step3 outputs: You can see "Waiting for guest domain to start" in virt-viewer terminal. So could move this bug from ON_QA to VERIFIED. For Comment2 I can reproduce the bug with builds: libvirt-0.10.2-55.el6.x86_64 spice-gtk-0.26-4.el6.x86_64 virt-viewer-2.0-7.el6.x86_64 qemu-kvm-0.12.1.2-2.481.el6.x86_64 usbredir-0.5.1-2.el6.x86_64 Try to verify this bug with builds: libvirt-0.10.2-55.el6.x86_64 spice-gtk-0.26-6.el6.x86_64 virt-viewer-2.0-8.el6.x86_64 qemu-kvm-0.12.1.2-2.481.el6.x86_64 usbredir-0.5.1-3.el6.x86_64 Steps to Reproduce: 1. Config ssh( so that host A can login host B without password.) # ssh-keygen # ssh-copy-id -i /root/.ssh/id_rsa.pub root.4.192 2. Make sure guest "2OS" is shutdown state on hostB and Run "virt-viewer -c qemu+ssh://10.66.4.192/system 2OS --wait" on host A, and then a "Waiting for guest domain to start" window pops up. 3. Stop libvirtd service on hostB # service libvirtd stop 4. Start libvirtd service on hostB again. # service libvirtd start Result now: Step3 outputs: You can see "Waiting for guest domain to start" in virt-viewer terminal. There is no error dialogue "Unable to connect to libvirt with URI: [none]" pop up any more, but it will not change the state to "Waiting for libvirt to start" in virt-viewer terminal. After confirmed with developer fidencio, he said:it is really a minor issue IMHO.If this is the only problem (but you can still connect to the guest) I would consider this bug as fixed. Step4 outputs: You can see "Waiting for guest domain to start" in virt-viewer terminal. So move this bug from ON_QA to VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0832.html |