From: Juan Quintela <quintela@redhat.com>
In-Reply-To: <4BFBF36D.8070208@codemonkey.ws> (Anthony Liguori's message of
	"Tue, 25 May 2010 10:57:33 -0500")
References: <cover.1274796992.git.quintela@redhat.com>
	<9b6575587d22a5c85ec536172810520ee3b945d5.1274796992.git.quintela@redhat.com>
	<4BFBE843.5070202@codemonkey.ws> <m34ohwhu3q.fsf@trasno.mitica>
	<4BFBF36D.8070208@codemonkey.ws>
Date: Tue, 25 May 2010 18:04:11 +0200
Message-ID: <m3ljb8ge84.fsf@trasno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 05/25/2010 10:35 AM, Juan Quintela wrote:

>> problem here is that libvirt start target with -S, and waits to do the
>> "cont" as soon as possible.  As of know, only way to do it is to poll
>> info migrate on source faster.
>>    
>
> Why does it do that??
>
> That sound like a terrible idea.

Becaues migration is not reliable, and they don't have a way to issue
cont only in one of the sides :(

We make migration protocol reliable, or management application have to
decide when migration suceeded or not.

This new events help then a lot.  But they issue the cont really fast
(before migration ends).  I don't remember why they did that.

danp?

>>> There should be some information about why it failed, no? Preferrably
>>> in a QError format.
>>>      
>> At this point, we have basically -1 :(
>>
>> I can add a field with an error number, but we are very bad at the
>> moment about moving errno's upstack.
>>    
>
> We need a better solution for reporting errors via notifications.

Suggestions?

Notice that what we need now is a way to know if migration ended with
success or in any other way, as soon as possible.

>>> I think this makes more sense as a MIGRATION_CONNECTED event.  It
>>> probably should carry peer information too.
>>>      
>> What kind of peer information?
>>
>> We have tcp/fd/exec/unix migrations.  calling it CONNECTED vs STARTED, I
>> don't care.  But adding information?  Notice that the management
>> application knows what it did, I can put the:
>>
>>   "exec: gzip -d<  /tmp/foo"
>>
>> string, but not much more that I can put here.
>>    
>
> Basically, do we have any useful information in info migrate that we
> can include?

(qemu) info migrate
Migration status: active
transferred ram: 874808 kbytes
remaining ram: 227912 kbytes
total ram: 1065344 kbytes
(qemu) 

I can't see anything interesting to put here :(

About the CONNECTED/STARTED distintion, I fully agree with danp.  We
just want STARTED event for migration, CONNECTION should be generated
(or not) for all sockets/char devices.  it don't make sense for fd/exec
for instance.

Later, Juan.