From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=38341 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PsHby-0000ju-Ly
	for qemu-devel@nongnu.org; Wed, 23 Feb 2011 11:30:47 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PsHbw-0005e8-Ko
	for qemu-devel@nongnu.org; Wed, 23 Feb 2011 11:30:46 -0500
Received: from mail-vw0-f45.google.com ([209.85.212.45]:59953)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PsHbw-0005dz-IR
	for qemu-devel@nongnu.org; Wed, 23 Feb 2011 11:30:44 -0500
Received: by vws19 with SMTP id 19so3936884vws.4
	for <qemu-devel@nongnu.org>; Wed, 23 Feb 2011 08:30:44 -0800 (PST)
Message-ID: <4D653625.6080502@codemonkey.ws>
Date: Wed, 23 Feb 2011 10:30:29 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
References: <20110222170004.808373778@redhat.com>	<20110222170115.710717278@redhat.com>	<4D642181.4080509@codemonkey.ws>
	<20110222210735.GA9372@amt.cnet>	<4D64266A.3060106@codemonkey.ws>
	<20110222230935.GA11082@amt.cnet>	<4D644343.4050800@codemonkey.ws>
	<4D65051A.6070707@redhat.com>	<4D651B20.70405@codemonkey.ws>
	<4D652852.60505@redhat.com>	<4D652F73.3000305@codemonkey.ws>
	<AANLkTin0qBb+enpROi_X-xdGKD6Bat2WN0aEr=C=_6au@mail.gmail.com>
In-Reply-To: <AANLkTin0qBb+enpROi_X-xdGKD6Bat2WN0aEr=C=_6au@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Jes.Sorensen@redhat.com, Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org

On 02/23/2011 10:17 AM, Peter Maydell wrote:
> On 23 February 2011 16:01, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> Yes.   I view the command line as optional.  To me, this is the ideal
>> interaction:
>>
>> 1) start qemu with an empty stateful config file
>>
>> 2) issue monitor commands to create all devices and backends
>>
>> 3) the stateful config file totally captures the state of all of the issued
>> QMP commands.  The management tool can relaunch the guest just by passing
>> the stateful config file to QEMU.
>>
>> 4) when the management tool needs to "extract" a config file, it can read
>> the stateful config (through the monitor) and generate it's own config.
>>
>> 5) the management tool should treat the stateful config file as more or less
>> opaque.  It shouldn't be visible to end user.
>>
>> In the non-managed case, users should interact directly with the config
>> file.
>>      
> For the typical TCG use case, that sounds a whole lot worse than
> the current situation of "just run qemu with a suitable command
> line"...
>    

This is only an option.  Running qemu with no stateful config and just 
using command line parameters will continue to be well supported.

Internally, no stateful config is essentially equivalent to using a 
stateful config in -snapshot mode where all of the changes are just 
lost.  The command line parameters will all eventually be implemented 
more or less in terms of internal QMP commands.

This is another reason for the QAPI refactoring.  -device handling (and 
all iterations of it) just becomes a call to qmp_device_add().

Regards,

Anthony Liguori

> -- PMM
>
>