On 01/20/2016 12:00 PM, Joao Martins wrote: > Introduce support for VIR_MIGRATE_PEER2PEER in libvirt migration. > Most of the changes occur at the source and no modifications > at the receiver. > > In P2P mode there is only the Perform phase so we must handle > the connection with the destination and actually perform the > migration. libxlDomainPerformP2P implements the connection to > the destination and let libxlDoMigrateP2P implements the actual s/let// > migration logic with virConnectPtr. In this function we take > of doing all phases of migration in the destination similar to
"... take care of doing..." ? > virDomainMigrateVersion3Full. We appropriately save the last > error reported in each of the phases to provide proper > reporting. We don't yet support VIR_MIGRATE_TUNNELED yet and One of those "yet" can be dropped. Even as an native English speaker, I'm not sure which one is the most correct to drop :-). > we always use V3 with extensible params, thus it also makes the > implementation simpler. > > It is worth noting that the receiver didn't have any changes, > and since it's still the v3 sequence thus it is possible to > migrate from a P2P to non-P2P host. > > Signed-off-by: Joao Martins <joao.m.mart...@oracle.com> > --- > Changes since v2: > - Remove Connect Close callback > > Changes since v1: > - Move Begin step to libxlDoMigrateP2P to have all 4 steps > together. > - Remove if before VIR_FREE(dom_xml) > --- > src/libxl/libxl_driver.c | 13 ++- > src/libxl/libxl_migration.c | 203 > ++++++++++++++++++++++++++++++++++++++++++++ > src/libxl/libxl_migration.h | 11 +++ > 3 files changed, 224 insertions(+), 3 deletions(-) Looks good other than the commit message nits. I do have a question about the job handling changes in 2 and 3 though. Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
