Chunyan Liu wrote:
>>>> "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.
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