qemu-devel
[Top][All Lists]
Advanced

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

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
Date: Tue, 25 May 2010 17:04:16 +0100
User-agent: Mutt/1.4.1i

On Tue, May 25, 2010 at 10:57:33AM -0500, Anthony Liguori wrote:
> On 05/25/2010 10:35 AM, Juan Quintela wrote:
> >Anthony Liguori<address@hidden>  wrote:
> >   
> >   
> >>     
> >>>+Data: None
> >>>+
> >>>+Example:
> >>>+
> >>>+{ "event": "MIGRATION_CANCELED",
> >>>+    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> >>>+
> >>>+MIGRATION_ENDED
> >>>+---------------
> >>>+
> >>>+Emitted when migration ends (both in source and target)
> >>>
> >>>       
> >>A start event is going to be generated already, no?
> >>     
> >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.

Historically QEMU gave no alternative. Adding these STARTED/ENDED 
events is to allow libvirt to detect start + end of migration 
reliably, avoiding the previous hacks QEMU forced us todo on the
dest, and avoid the high rate polling we had no choice but todo
on the source.

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

info migrate just includes the progress info + state (running, finished, 
cancelled, failed). The event itself replicates state. I don't see a hugely
compelling need to include the progress info in the FINISHED/CANCELLED
events. If really needed, the app can still call 'info migrate' to get it.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



reply via email to

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