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.
(In reply to Marc-Andre Lureau from comment #3)
> raising severity, moving to 3.4? It would be nice to try to fix it in RHEL
> first, I don't think there is windows specific issues here.
can you add the bug in rhel with rhel 6.6 target, and add depend on it in this bug?
thanks
moving to 3.4 this one
Comment 5Marc-Andre Lureau
2013-11-08 20:57:31 UTC
(In reply to David Blechter from comment #4)
> (In reply to Marc-Andre Lureau from comment #3)
> > raising severity, moving to 3.4? It would be nice to try to fix it in RHEL
> > first, I don't think there is windows specific issues here.
>
> can you add the bug in rhel with rhel 6.6 target, and add depend on it in
> this bug?
>
ok, but not until we have reproduced on rhel.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015.
Please review this bug and if not a blocker, please postpone to a later release.
All bugs not postponed on GA release will be automatically re-targeted to
- 3.6.1 if severity >= high
- 4.0 if severity < high
(In reply to Sandro Bonazzola from comment #7)
> this is an automated message. oVirt 3.6.0 RC3 has been released and GA is
> targeted to next week, Nov 4th 2015.
> Please review this bug and if not a blocker, please postpone to a later
> release.
> All bugs not postponed on GA release will be automatically re-targeted to
>
> - 3.6.1 if severity >= high
> - 4.0 if severity < high
agree, moving to 4.0
Hi, while testing migration I could reproduce similar bug here. I believe that the issue is around authentication actually. RHV issues a password valid for 120s and on migration we can't keep the validation from $src host to $dst host, as far as I can see. This likely would need a new migration protocol, if I'm not mistaken. Does it seem like an important RFE?
If I'm correct, with recent virt-viewer + spice-gtk you would see earlier logs with something like:
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.415: ../src/channel-main.c:2173 migrate_channel_connect 1:0
...
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.415: ../src/spice-channel.c:141 0x7e8c50:main-1:0: spice_channel_constructed
...
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.725: ../src/spice-channel.c:1934 0x7e8c50:main-1:0: switching to tls
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.725: ../src/spice-channel.c:2680 0x7e8c50:main-1:0: Coroutine exit main-1:0
...
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.869: ../src/spice-channel.c:2000 0x7e8c50:main-1:0: use mini header: 1
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.891: ../src/spice-channel.c:1274 0x7e8c50:main-1:0: link result: reply 7
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.891: ../src/spice-channel.c:2680 0x7e8c50:main-1:0: Coroutine exit main-1:0
> (remote-viewer:20603): GSpice-DEBUG: 11:25:07.891: ../src/spice-channel.c:2871 0x7e8c50:main-1:0: reset
and then some logs for the other channels like:
> (remote-viewer:20603): GSpice-DEBUG: 11:25:26.493: ../src/spice-channel.c:1066 inputs-3:0: Closing the connection: spice_channel_read() - ret=0
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 (spice-client-win bug fix and enhancement update), 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/RHEA-2021:1947