On Wed, Oct 01, 2014 at 10:45:33AM +0200, Cristian KLEIN wrote:
> On 2014-09-30 17:16, Daniel P. Berrange wrote:
> >On Tue, Sep 30, 2014 at 05:11:03PM +0200, Jiri Denemark wrote:
> >>On Tue, Sep 30, 2014 at 16:39:22 +0200, Cristian Klein wrote:
> >>>Signed-off-by: Cristian Klein <cristian.klein@xxxxxxxxx>
> >>>---
> >>> include/libvirt/libvirt.h.in | 1 +
> >>> src/libvirt.c | 7 +++++++
> >>> 2 files changed, 8 insertions(+)
> >>>
> >>>diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> >>>index 5217ab3..82f3aeb 100644
> >>>--- a/include/libvirt/libvirt.h.in
> >>>+++ b/include/libvirt/libvirt.h.in
> >>>@@ -1225,6 +1225,7 @@ typedef enum {
> >>> VIR_MIGRATE_ABORT_ON_ERROR = (1 << 12), /* abort migration on I/O errors happened during migration */
> >>> VIR_MIGRATE_AUTO_CONVERGE = (1 << 13), /* force convergence */
> >>> VIR_MIGRATE_RDMA_PIN_ALL = (1 << 14), /* RDMA memory pinning */
> >>>+ VIR_MIGRATE_POSTCOPY = (1 << 15), /* enable (but don't start) post-copy */
> >>> } virDomainMigrateFlags;
> >>
> >>I still think we should add an extra flag to start post copy
> >>immediately. To address your concerns about it, I don't think it's
> >>implementing a policy in libvirt. It's for apps that want to make sure
> >>migration converges without having to spawn another thread and monitor
> >>the progress or wait for a timeout. It's a bit similar to migrating a
> >>paused domain vs. migrating a running domain and pausing it when it
> >>doesn't seem to converge.
> >
> >Your point about spawning another thread makes me wonder if we should
> >actually look at adding a 'VIR_MIGRATE_ASYNC' method (that would require
> >P2P migration of course). If this flag were set, virDomainMigrateXXX would
> >only block for long enough to start the migration and then return.
> >
> >Callers can use the job info API to monitor progress & success/failure.
> >
> >Then we wouldn't have to keep adding flags like you suggest - apps can
> >just easily call the appropriate API right away with no threads needed
>
> This would make a lot of sense. The user would call:
>
> """
> virDomainMigrateXXX(..., VIR_MIGRATE_POSTCOPY | VIR_MIGRATE_ASYNC)
> virDomainMigrateStartPostCopy(...)
> """
>
> Would this be seen as more cumbersome than having a dedicated
> VIR_MIGRATE_POSTCOPY_AUTOSTART?
I think it is still acceptably simple - the root complaint that Jiri
had was that he doesn't want apps to have to spawn threads, which
this proposal of mine achieves.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list