qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events
Date: Thu, 17 Jun 2010 18:34:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Luiz Capitulino <address@hidden> wrote:
> On Wed, 16 Jun 2010 21:10:04 +0200
> Juan Quintela <address@hidden> wrote:
>
>> Luiz Capitulino <address@hidden> wrote:
>> > On Tue, 15 Jun 2010 17:24:59 +0200
>> > Juan Quintela <address@hidden> wrote:
>> 
>> >> >
>> >> >  I still don't see the need for MIGRATION_STARTED, it could be useful in
>> >> > the target but I'd like to understand the use case in more detail.
>> >> 
>> >> At this point, if you are doing migration with tcp, and you are putting
>> >> the wrong port on source (no path or any other error), you get no info
>> >> at all of what is happening.
>> >
>> >  Shouldn't the migrate command just the return the expected error?
>> 
>> No.  Think you are "having troubles".  You try to find what happens.
>> launch things by hand.  And there is no way to know if anybody has
>> conected to the destination machine.  Some notification that migration
>> has started is _very_ useful.  expecially when there are
>> networks/firewalls/... in the middle.
>
>  [...]
>
>> That is it.  But you continue telling that going to the old house and
>> doing a info migrate is a good interface.
>
>  I'm sorry? When did I ever claimed such a thing?

polling is enough.  polling has to be done in source machine.

>  First point: all you describe is MIGRATION_CONNECTED, at the end of the day
> it would do exactly what you want for MIGRATION_STARTED.
>
>  The second, and most important point, is that we're trying not to make
> things worse. Adding a number of events to circumvent a bad designed
> command and having the wrong expectations (ie. help developer debugging)
> is a clear recipe for disaster.
>
>  Anyway, I think it doesn't matter anymore, as QMP is not going to be declared
> stable for 0.13. In this case we'll have enough time to design the proper
> interface.
>
>> To add insult to injury, the problem is that libvirt people are not
>> collaborative, and expect things that can't be done, are uncooperative,
>
>  Again, I've never claimed that and I think you're taking this thread to
> the wrong direction.

Ok, I stop then.

Later, Juan.




reply via email to

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