[Kimchi-devel] [RFC] Live migration backend + API

[Daniel Henrique Barboza]

On 10/16/2015 03:41 PM, Aline Manera wrote:
>
>
> On 15/10/2015 16:18, Daniel Henrique Barboza wrote:
>> Hi,
>>
>> Live migration will be one of the new features for Kimchi 2.0 and 
>> I've been investigating it for a week or so. This is how I'm planning 
>> to implement it:
>>
>> - API:
>>
>> The API will be similar to the API of the 'cloneGuest', but with 
>> extra parameters:
>>
>> url : 'plugins/kimchi/vms/' +'vm_name' + "/migrate"
>> type: 'POST'
>> parameters:
>> * destination: the IP address of the destination host
>> * (optional, not sure if applicable) password: the password to log in 
>> the destination via ssh tunnel
>
> In addition to password, you will need the username as well (if 
> applicable as you said)

Good point. Let me review that:

url : 'plugins/kimchi/vms/' +'vm_name' + "/migrate"
type: 'POST'
parameters:
* destination: the IP address of the destination host
* (optional) user: the user to be used in the migration. If not defined, 
defaults to 'root'
* (optional, not sure if applicable) password: the password to log in 
the destination via ssh tunnel


>
>>
>> In my opinion we can start with a 'migrate' button in the options of 
>> the VM, which will open up a new window to insert the destination IP 
>> address. This of course thinking about the old UI. I believe we can 
>> do whatever it is done with the 'Clone' function in the case of the 
>> new UI, with this extra window.
>>
>> As the migration might take a while, we'll need a progress bar or 
>> something to demonstrate that the progress is still ongoing. Again, 
>> the same thing as clone does :)
>>
>> - backend and core functionality:
>>
>> This is where it gets tricky. Libvirt has *a lot* of ways to do a 
>> live migration between hosts. My approach, at least for this first 
>> attempt, will be focusing in a single way, implement it, stabilize it 
>> and then extend it to the other migration types, if necessary.
>>
>> Same thing goes for the preset up. The only way I managed to do a 
>> live migration was with a NFS storage pool in both hosts, same name 
>> and same NFS server.
>
> Does the user need to specify which NFS pool to use during migration?
>
>> This shared storage is necessary because the live migration will 
>> *not* copy the disks of the VM, just the RAM memory. I had to share 
>> ssh keys between the hosts to allow for password less ssh sessions.
>>
>> At first, I want to relieve this first implementation from this pre 
>> config, which will have to be done entirely by the user. If 
>> everything goes well, I can add a few automation in this process 
>> inside the backend before the 2.0 launch.
>>
>> Kimchi internals will be implemented by using async task facilities.
>>
>>
>>
>> Any questions? Comments?
>>
>>
>>
>> Daniel
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>