
On 16/10/2015 15:41, 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)
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?
Forget it. I've better understood that in the follow up emails.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel