[libvirt] [PATCH v2 1/8] Added public API to enable post-copy migration

[Jiri Denemark]

On Wed, Oct 01, 2014 at 10:45:33 +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 at cs.umu.se>
> >>> ---
> >>>   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?

The ASYNC flag Daniel suggested makes sense, so I guess you can just
ignore my request for a special flag. Although, I don't think the ASYNC
stuff needs to be done within this series, let's just focus on the
post-copy stuff.

Jirka