From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
Date: Tue, 25 May 2010 17:04:16 +0100 [thread overview]
Message-ID: <20100525160416.GP31759@redhat.com> (raw)
In-Reply-To: <4BFBF36D.8070208@codemonkey.ws>
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<anthony@codemonkey.ws> 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 :|
next prev parent reply other threads:[~2010-05-25 16:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 14:21 [Qemu-devel] [PATCH v2 0/5] Add QMP migration events Juan Quintela
2010-05-25 14:21 ` [Qemu-devel] [PATCH 1/5] Exit if incoming migration fails Juan Quintela
2010-05-25 18:01 ` Luiz Capitulino
2010-05-25 18:37 ` [Qemu-devel] " Juan Quintela
2010-05-25 18:52 ` Anthony Liguori
2010-05-25 14:21 ` [Qemu-devel] [PATCH 2/5] Factorize common migration incoming code Juan Quintela
2010-05-25 14:21 ` [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events Juan Quintela
2010-05-25 15:09 ` Anthony Liguori
2010-05-25 15:35 ` [Qemu-devel] " Juan Quintela
2010-05-25 15:52 ` Daniel P. Berrange
2010-05-25 15:57 ` Anthony Liguori
2010-05-25 16:04 ` Juan Quintela
2010-05-25 16:10 ` Anthony Liguori
2010-05-25 18:13 ` Luiz Capitulino
2010-05-25 16:04 ` Daniel P. Berrange [this message]
2010-05-25 16:04 ` Juan Quintela
2010-05-25 16:25 ` Daniel P. Berrange
2010-05-25 16:33 ` Anthony Liguori
2010-05-25 16:43 ` Juan Quintela
2010-05-26 10:33 ` Daniel P. Berrange
2010-05-26 14:54 ` Anthony Liguori
2010-05-26 15:15 ` Daniel P. Berrange
2010-05-26 16:55 ` Anthony Liguori
2010-05-27 13:48 ` Luiz Capitulino
2010-05-27 15:58 ` Juan Quintela
2010-05-27 16:07 ` Luiz Capitulino
2010-05-27 16:07 ` Anthony Liguori
2010-05-26 10:16 ` Daniel P. Berrange
2010-05-25 18:21 ` Luiz Capitulino
2010-05-25 18:38 ` Juan Quintela
2010-05-25 15:48 ` [Qemu-devel] " Daniel P. Berrange
2010-05-25 18:31 ` Luiz Capitulino
2010-05-25 18:51 ` Anthony Liguori
2010-05-26 13:14 ` Luiz Capitulino
2010-05-25 14:21 ` [Qemu-devel] [PATCH 4/5] QMP: Emit migration events on incoming migration Juan Quintela
2010-05-25 14:21 ` [Qemu-devel] [PATCH 5/5] QMP: Emit migration events on outgoing migration Juan Quintela
-- strict thread matches above, loose matches on Subject: below --
2010-05-24 8:25 [Qemu-devel] [PATCH 0/5] Add QMP migration events Juan Quintela
2010-05-24 8:25 ` [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events Juan Quintela
2010-05-24 9:04 ` [Qemu-devel] " Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100525160416.GP31759@redhat.com \
--to=berrange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.