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
