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

[Anthony Liguori]

On Feb 28, 2011 7:21 AM, "Avi Kivity" <address@hidden> wrote:
>
> 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.

No, you're just impervious to my subtle attempt to refocus the discussion on solving a practical problem.

There's a lot of good, reasonably straight forward changes we can make that have a high return on investment.  The only suggestion I'm making beyond Marcelo's original patch is that we use a structured format and that we make it possible to use the same file to solve this problem in multiple places.

I don't think this creates a fundamental break in how management tools interact with QEMU.  I don't think introducing RAID support in the block layer is a reasonable alternative.

Regards,

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