Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy

[Avi Kivity <avi@redhat.com>]

On 02/28/2011 02:45 PM, Anthony Liguori wrote:
> On 02/28/2011 02:38 AM, Avi Kivity wrote:
>>>
>>> We don't separate configuration from guest state today.  Instead of 
>>> setting ourselves up for failure by setting an unrealistic standard 
>>> that we try to achieve and never do, let's embrace the system that 
>>> is working for us today.  We are authoritative for everything and 
>>> guest state is intimately tied to the virtual machine configuration.
>>
>> "we are authoritative for everything" is a clean break from 
>> everything that's being done today.  It's also a clean break from the 
>> model of central management plus database.  We can't force it on people.
>
> No, it isn't.  This has been the way QEMU has always been.
>
> QEMU has always and will always continue to be useful in the absence 
> of a management layer.  That means that it will mix modifications to 
> configuration with guest actions.
>
> To avoid races, a management tool needs to either poll QEMU or listen 
> for events to know when QEMU initiates a configuration change.  This 
> is how tools are written today.
>
> The only thing being discussed is how to handle a very small and rare 
> race condition whereas QEMU may send an notification to a crashed 
> management tool *and* QEMU crashes before the management tool restarts.
>
> The only two options to solve this problem are synchronous 
> notifications or a QEMU global state file.  Since the former is a 
> radical change to our existing API, the later is a much more 
> reasonable option.
>
> If a management tool doesn't care about this race, it can simply not 
> use the global state file.

You're just ignoring what I've written.

-- 
error compiling committee.c: too many arguments to function