qemu-devel
[Top][All Lists]
Advanced

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

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


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
Date: Mon, 28 Feb 2011 15:21:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

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




reply via email to

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