Bug 1285163 - Error massage pop up "Unable to connect to libvirt with URI: [none]." continuously when stop libvirtd service
Error massage pop up "Unable to connect to libvirt with URI: [none]." continu...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.8
x86_64 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Virt Viewer Maint
Virtualization Bugs
:
Depends On: 1246022
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-25 01:20 EST by mxie@redhat.com
Modified: 2016-05-10 17:19 EDT (History)
10 users (show)

See Also:
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 17:19:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 2 mxie@redhat.com 2015-11-30 03:09:00 EST
When use "virt-viewer -c qemu+ssh://10.66.4.192/system 2OS --wait" connecting to a remote host‘s shutdown guest, then stop libvirtd service on remote host, error message "Unable to connect to libvirt with URI: qemu+ssh://10.66.4.192/system." pop up continuously though i click "OK" button


Version-Release number of selected component
virt-viewer-2.0-7.el6.x86_64
libvirt-0.10.2-55.el6.x86_64
Comment 4 mxie@redhat.com 2015-12-14 05:06:46 EST
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@10.66.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.
Comment 6 errata-xmlrpc 2016-05-10 17:19:08 EDT
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

Note You need to log in before you can comment on or make changes to this bug.