Chunyan Liu wrote: >>>>> "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. Ah yes, I noticed that but forgot to mention it - sorry. > 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? > You can use a virBitmap to keep track of used ports. The qemu driver uses a virBitmap to keep track of used vnc ports, e.g. see qemuProcessNextFreePort() in src/qemu/qemu_process.c. Perhaps the same range of ports qemu uses for migration (i.e. when a port is not specified by the user) can be used in the libxl driver, allowing firewalls and the like to be configured similarly between the two. Thanks, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list