7:15 a.m.
On 15.10.2015 21: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 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 :)
This progress bar may be a little bit tricky
because depending on the
workload of the VM the amount of dirty pages could increase again at a
certain point. But from a user point of view I really would like to get
the reality, meaning to see regression as well in order to give me the
chance to react.
- 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.
Makes a lot of sense.
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. 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.
From what I remember there is a validation step before starting
migration where libvirt is checking if the resources of the VM are
available on the remote host as well. I suspect the check is that simple
to define and start the domain in listen mode on the remote host by
using the domain xml from the target. And I guess this one would already
fail if the artifacts specified in the domain xml are not present.
Live migration has an option to perform volume migration as well ( it's
"copy-storage-all" in virsh I think), but I have never tried it out.
Are you planning to support also FCP attached storage ? I guess this one
could work:
- if both Hosts have access to the LUN
- the disk-id used in the domain definition is the same on source and
target:
- for example by using the multipathing id like
36005076802810d504800000000002c1d
- because sda on source could point to a different disk as sda
on target.
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?
Are you planning to offer a "cancel live migration" API and task as well
? I'm thinking of the situation where migration will not converge due to
high workload on the VM and the user may decide to stop it ?
Is this migration going to be supported only from one Kimchi managed
host to another or could the target host be also a non Kimchi managed host ?
Are we planning to transfer also Kimchi-template data to the target host
in case this one is managed by Kimchi ?
Daniel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel