Hi All, While testing the agent selection patches I found a bug in spice-gtk which in turn triggered a bug in spice-server wrt agent handling. As demonstrated by the recent server agent patch set I did this led to me finding another bug, etc...
While looking into this I've also taken a quick look at the saving / restoring of agent related state (basically the VDIPortState contents) over a migration. There is code in server/reds.c to handle this, but it only does so in the seamless migration case! Since we don't support seamless migration atm, this means that effectively all state in VDIPortState does not get kept over a migration. This means that: * If the agent is halfway through sending an agent message chunk when we switch to the new vm, we will see the data halfway through the chunk as a chunk header, declare it invalid and disconnect the agent (not good (tm)). * If there was any data from the client queued to be delivered to the agent when we switch to the new vm, all queued data is lost (not good (tm)). Also I must say I don't understand why in the seamless case the *servers* agent state (such as it state wrt parsing a chunk being send from the agent, which could be a chunk destined for the server) is being send to the new through the client at all, this makes no sense, this should be using qemu's normal migration mechanisms (*). So long story short someone (hint preferably not me I would like to get back to usb work again) needs to look into properly implementing migration for the vdiportstate (and maybe also other mainchannel related state). Regards, Hans *) I believe this may be an example of "once you have a hammer everything looks like a nail" example, iow I have the theory this was implemented through seamless, because back when it was implemented seamless migration was seen as the solution to all migration related problems. _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel