[Top][All Lists]

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

[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events

From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
Date: Tue, 25 May 2010 18:04:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> 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.


>>> 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.


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

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.

reply via email to

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