Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Michael Roth]

On 02/21/2011 02:32 AM, Jes Sorensen wrote:
> On 02/18/11 15:57, Anthony Liguori wrote:
> > On 02/18/2011 08:30 AM, Jes Sorensen wrote:
> > > However if there's an agent connection, it could be arranged in a way
> > > allowing the host to reconnect to the guest agent. In that way it really
> > > shouldn't be a big deal as long as our agent commands aren't too complex.
> >
> > Oh, but they'll be nice and complex :-)  What happens if you do a live
> > migration in the middle of doing a live backup?  You'll end up with the
> > guest waiting to be told that it's okay to unfreeze itself only to never
> > be told.
>
> Well that isn't really different from the current setup - if QEMU
> migrates, the admin tool has to connect to the new QEMU process and
> issue the fsthaw command there instead.

Another thing to consider is that virtagent is bi-directional, and may 
be tracking the state of state-full RPCs on behalf of the guest client, 
just as the guest daemon may be tracking the state of stateful RPCs on 
behalf of the host client. We cannot maintain consistent state without 
migrating the host-side state information along with the guest.

The admin tool in your example, i.e. libvirt, is different in this 
regard, since it is purely a client and not a client/server like the 
host and guest components of virtagent. It doesn't need to maintain any 
state between migrations.

> Jes