Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Using virt-viewer connects to a shutoff guest with <listen type='none'/>, then start guest,finding virt-viewer windows keeps showing "Waiting for guest domain to start" and warning "Display can only be attached through libvirt with --attach" prompts in command line.
Version-Release number of selected component (if applicable):
virt-viewer-2.0-12.el7.x86_64
spice-gtk3-0.31-6.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Prepare a shutoff spice guest which <listen type='none'>.
# virsh dumpxml rhel6.8
...
<graphics type='spice'>
<listen type='none'/>
</graphics>
...
2. Using virt-viewer connects to guest rhel6.8, virt-viewer window showing: "Waiting for guest domain to start"
# virt-viewer rhel6.8
3. Then start guest.
# virsh start rhel6.8
Domain rhel6.8 started
Actual results:
1. After guest starts, there is just a warning in virt-viewer command line:
# virt-viewer rhel6.8
(virt-viewer:15666): virt-viewer-WARNING **: Display can only be attached through libvirt with --attach
2. virt-viewer windows keeps showing "Waiting for guest domain to start".
Expected results:
Prompts "Display can only be attached through libvirt with --attach" warning in virt-viewer window when guest starts.
Additional info:
1.
When use virt-viewer connect to a running guest <listen type='none'> without "-a" option directly, error "Failed to connect: Display can only be attached through libvirt with --attach" shows in window, after click "OK", window will closed and command exit.
2.
Can also reproduce with vnc guest which <listen type='none'>.
Comment 1Christophe Fergeau
2016-10-24 10:29:37 UTC
(In reply to zhoujunqin from comment #0)
> 1.
> When use virt-viewer connect to a running guest <listen type='none'> without
> "-a" option directly, error "Failed to connect: Display can only be attached
> through libvirt with --attach" shows in window, after click "OK", window
> will closed and command exit.
Or virt-viewer could just fallback to --attach behaviour when it detects a guest where --attach has to be used
> Or virt-viewer could just fallback to --attach behaviour when it detects a
> guest where --attach has to be used
Do you mean virt-viewer will not report any error and connect to guest automatically with --attach implied?
If yes, it may have a little confusion for users when they connect to the guest again when it's running. Because they have to add --attach for a running guest.
Thanks
Comment 3Christophe Fergeau
2016-10-27 08:12:10 UTC
(In reply to xiaodwan from comment #2)
> > Or virt-viewer could just fallback to --attach behaviour when it detects a
> > guest where --attach has to be used
>
> Do you mean virt-viewer will not report any error and connect to guest
> automatically with --attach implied?
>
> If yes, it may have a little confusion for users when they connect to the
> guest again when it's running. Because they have to add --attach for a
> running guest.
It would have to do that in all cases. Actually, for this bug report, I think we'd get the same warning if the guest is already running ?
(In reply to Christophe Fergeau from comment #3)
> (In reply to xiaodwan from comment #2)
> > > Or virt-viewer could just fallback to --attach behaviour when it detects a
> > > guest where --attach has to be used
> >
> > Do you mean virt-viewer will not report any error and connect to guest
> > automatically with --attach implied?
> >
> > If yes, it may have a little confusion for users when they connect to the
> > guest again when it's running. Because they have to add --attach for a
> > running guest.
>
> It would have to do that in all cases. Actually, for this bug report, I
> think we'd get the same warning if the guest is already running ?
Now an error dialog pops and ask user to add "--attach" option if the guest is running.
If do that in all cases, then "--attach" option will be redundant.
I verified it with virt-viewer-5.0-2.el7.x86_64.
if don't specify --attach when connecting to a shutdown guest, after start up the guest, Error "Display can only be attached through libvirt with --attach" displays in virt-viewer window.
If specify --attach when connecting to a shutdown guest, after start up the guest, virt-viewer can connect to the guest successfully.
So move the 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://access.redhat.com/errata/RHBA-2017:1849