Hide Forgot
Description of problem: When migrating Windows guest on RHEVM3.0, spice client is disconnected and it's not able to connect back because of non-responsive vdagent. If I connect to such guest using Admin portal, I can see vdagent service is up and running, but vdagent is not functional at all - no client mouse, no copy-paste. If I connect to guest through Admin portal and do migration everything works fine. Version-Release number of selected component (if applicable): RHEVM3.0 ic130.1 Host: RHEL6.1 (spice-server-0.8.0-1, qemu-kvm-0.12.1.2-2.169) Guest: WinXP with ic114 tools Client: RHEL6.2 (spice-client-0.8.0-2) How reproducible: always Steps to Reproduce: 1. Connect to Windows guest using User portal of RHEVM3.0 2. Using Admin portal migrate the guest Actual results: spice window is closed, It's not possible to connect to the guest again using user portal Expected results: spice client persist to open and display guest Additional info: Client log: 1311191551 INFO [16770:16770] Application::switch_host: host=aaaa.spice.lab.eng.brq.redhat.com port=5900 sport=5901 1311191552 INFO [16770:16771] RedPeer::connect_unsecure: Trying X.X.X.X 5901 1311191552 INFO [16770:16771] RedPeer::connect_unsecure: Connected to 10.34.58.4 5901 1311191582 WARN [16770:16771] RedChannel::run: abort 1311191582 ERROR [16770:16770] main: unhandled exception: vdagent timeout
Isn't this just another symptom of 722980? We need to retest this when that bug is fixed.
(In reply to comment #1) > Isn't this just another symptom of 722980? > We need to retest this when that bug is fixed. AMAIK 722980 was not reproduced on xp guest. Seems more like a duplicate of 718463.
I did some more testing with following results: Originally reported problem with unresponsive (even running) vdagent which I reported here does happen when using vdagent from ic114 tools (which are still recommended with ic130.1 build of RHEVM). Because I saw in the bug mentioned by Arnon that It was reported by Yonit and that's why most likely reproduced on something much newer I used latest vdagent-win-0.1-6. I am not observing the problem with non-responsive vdagent anymore. But another problem occurs: during migration spice-client is closed with: 1311265157 INFO [3551:3551] Application::switch_host: host=hyper03.spice.lab.eng.brq.redhat.com port=5906 sport=5907 1311265158 INFO [3551:3552] RedPeer::connect_unsecure: Trying 10.34.58.4 5907 1311265158 INFO [3551:3552] RedPeer::connect_unsecure: Connected to 10.34.58.4 5907 1311265158 WARN [3551:3552] RedChannel::run: connect failed 7 1311265158 INFO [3551:3551] main: Spice client terminated (exitcode = 3) and after manual reconnecting mouse is not working until restarting of vdagent as Yonit reports in bz #718463. I am not sure when and how builds from brew will get into iso tools. As well as whether in Yonit's case spice client was closed during migration.
Btw only one thing which differs in both scenario is different version of vdagent to be clear.
What is the version number (And download location) of the working agent?
(In reply to comment #6) > What is the version number (And download location) of the working agent? https://brewweb.devel.redhat.com/buildinfo?buildID=163867 But It does not work either, as I described in previous comment #4, It does not work different way. When using the one from ic tools and doing migration, vdagent is non resposive and client is closed because of vdagent timeout. When using the newer one from brew (https://brewweb.devel.redhat.com/buildinfo?buildID=163867), spice client closes during migration and after manual reconnecting spice display comes out but cursor of mouse is not visible until restart of vdagent. And this behaviour in all cases is related to migration.
To be clear - all this vdagent beahviour is related to migration and not to agent unstability reported in bz #722980.
Because There are more bugs about migration I wanna sort that out a little bit: Problem with closing Spice client during migration is reported in bug: https://bugzilla.redhat.com/show_bug.cgi?id=725009 Problem with not working mouse after migration is reported in bug: https://bugzilla.redhat.com/show_bug.cgi?id=718463 This bug is about non-responsive agent (that's why timeouting) after migration reproduced on ic114 tools (imho not related to bug #722980). Moreover this bug is not reproducible on newer build of vdagent from brew (https://brewweb.devel.redhat.com/buildinfo?buildID=163867) where two bugs mentioned above occur. That's why after fixing those two bugs we need to retest this one and as well as solving out Yaniv's question in comment #2.
I am going to retest this soon wrt fixes #673973.
Please try to repro with qemu-kvm-0.12.1.2-2.176.el6. Seems like we can close as NOTABUG / duplicate of BZ #725965, since it was a qemu issue.
(In reply to comment #10) > I am going to retest this soon wrt fixes #673973. It has nothing to do with #673973, see comment 11.
*** This bug has been marked as a duplicate of bug 725965 ***
(In reply to comment #12) > (In reply to comment #10) > > I am going to retest this soon wrt fixes #673973. > > It has nothing to do with #673973, see comment 11. It has sth to do with #673973, just try please migration with stopped agent using spice-client 0.8.0-2 (without fix from #673973) and then using spice-client 0.8.2-3 (with the fix). In first case migration will fail with spice client error as described in original description. The fix from #673973 fixes this issue indirectly. spicec 0.8.0-2 is shipped in RHEL6.1. I would really appreciate If I am read carefully and what the bug report is about... ... whatever.
(In reply to comment #15) > (In reply to comment #12) > > (In reply to comment #10) > > > I am going to retest this soon wrt fixes #673973. > > > > It has nothing to do with #673973, see comment 11. > > It has sth to do with #673973, just try please migration with stopped agent > using spice-client 0.8.0-2 (without fix from #673973) and then using > spice-client 0.8.2-3 (with the fix). In first case migration will fail with > spice client error as described in original description. The fix from #673973 > fixes this issue indirectly. spicec 0.8.0-2 is shipped in RHEL6.1. > I would really appreciate If I am read carefully and what the bug report is > about... > ... whatever. That's why I do believe It's not a dup of bug #725965.
It does not occur due to changes in so that since spice-client-0.8.2-1.el6 spicec-win-0.1-5. Tested!
(In reply to comment #18) > It does not occur due to changes in so that since spice-client-0.8.2-1.el6 > spicec-win-0.1-5. Tested! Due to changes in bug #673973