On Mon, Apr 04, 2011 at 01:34:22PM +0200, Hans de Goede wrote: > 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 (*).
There is also the possibly related issue of lack (and opposition) to bi directional migration protocol for qemu. > > 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 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
