>>>> "Chun Yan Liu" <cyliu@xxxxxxxx> 3/6/2012 2:29 PM >>> >> I didn't get a chance to test this yet, but have some initial review >> comments. >> >>> Signed-off-by: Chunyan Liu >>> --- >>> src/libxl/libxl_driver.c | 617 >>> ++++++++++++++++++++++++++++++++++++++++++++++ >>> src/libxl/libxl_driver.h | 17 ++- >>> 2 files changed, 632 insertions(+), 2 deletions(-) >>> >>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c >>> index d5fa64a..4037635 100644 >>> --- a/src/libxl/libxl_driver.c >>> +++ b/src/libxl/libxl_driver.c >>> @@ -30,6 +30,12 @@ >>> #include >>> #include >>> #include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> >>> #include "internal.h" >>> #include "logging.h" >>> @@ -60,6 +66,13 @@ >>> #define XEN_SCHED_CREDIT_NPARAM 2 >>> >>> static libxlDriverPrivatePtr libxl_driver = NULL; >>> +static virThread migrate_receive_thread; >>> >> >> This prevents receiving concurrent migrations. > Yes. It is a problem. Defined as "static" is to be used in Begin3 function > virThreadCreate and in Finish3() function virThreadJoin, but actually the > thread will exit when receiving data completed or meets error, so > virThreadJoin doesn't have much effect here. If a call of virThreadJoin is > not needed, then can specify migrate_receive_thread as a local variable. About concurrent migrations, there is another problem in migration port. Every time a migration operation is issued, it will create a socket connection between source and host to transfer data. If a port specified, target side will create a socket and bind to that port, otherwise will bind to a DEFAULT_MIGRATION_PORT (current implementation). But if 1st migration occupies the DEFAULT_MIGRATION_PORT, then 2nd migration (without specifying port) will fail to bind to the DEFAULT_MIGRATION_PORT again. So, to ensure concurrent migrations, perhaps we need a group of ports for migration usage, every migration operation probes for a usable port. How do you think? Thanks, Chunyan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list