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

[Aline Manera]

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)

>
> 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
>