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

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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel