>>> "Chun Yan Liu" <cyliu(a)suse.com> 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