[libvirt] [PATCH] Add migration APIs for libxl driver

[Jim Fehlig]

Chunyan Liu wrote:
>>>>> "Chun Yan Liu" <cyliu at 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