qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent
Date: Fri, 18 Feb 2011 08:57:01 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

On 02/18/2011 08:30 AM, Jes Sorensen wrote:
On 02/18/11 15:07, Anthony Liguori wrote:
On 02/18/2011 06:45 AM, Jes Sorensen wrote:
It may not be so fundamental, but it still makes me wary. XMLRPC
handling is quite high level and introduces the potential of errors that
are outside of our direct control. Personally I don't see the big
benefit of having virtagent terminate in QEMU,
Live migration.  If it's a separate daemon, then live migration gets fugly.

If xmlrpc-c is a PoS, then we ought to look at using something else.
But let's understand what's happening first before drawing any conclusions.
Urgh, I always do my best to pretend that there is no such thing as live
migration :) Never seem to work though :(

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.

Terminating in QEMU means we can do intelligent things like delay live migration convergence, save state, etc.

Regards,

Anthony Liguori

xmlrpc-c is probably fine, but it introduces a layer of complexity which
always makes me worried.

Cheers,
Jes




reply via email to

[Prev in Thread] Current Thread [Next in Thread]