[Spice-devel] agent server code migration code is broken / non existent

[Hans de Goede]

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.