[Kimchi-devel] [WIP PATCH 5/5] Add feature to clone VMs

Crístian Viana vianac at linux.vnet.ibm.com
Tue Oct 21 13:58:38 UTC 2014


On 17-10-2014 14:38, Daniel H Barboza wrote:
> Crístian, have you considered using virt-clone?
>
> http://linux.die.net/man/1/virt-clone
>
> It is a tool that seems to be widely supported by the distros and it 
> could simplify your code at the cost of depending on yet another 
> command line utility.

Yes, I have, but I don't think it adds enough value.

If we had used virt-clone now in this patchset, the only function which 
would be simplified is _do_clone (PATCH 5/5), which is the function that 
actually clones the VM. All other changes would still be needed. And the 
most complex part of this patchset (IMO), which I haven't sent yet and 
is still to be implemented, is how to deal with the different storage 
pools and take decisions on how to clone automatically taking into 
account the context of Kimchi (e.g. clone to the pool 'default' when 
there's not enough space on the original one). By default, virt-clone 
always tries to create new files in the same directories as the existing 
disks and it fails if that's not possible. I am aware of the virt-clone 
flag "-f", which is how we can specify manually where the new disks will 
be saved. But if we still need to write our own logic to find out where 
the new disks will be saved and set them by using "-f", virt-clone 
itself will only perform the following operations: duplicate the 
original VM's XML descriptor, set the new VM name, UUID and MAC 
addresses, and cp the disk files specified by us. I don't think that 
depending on a package to run it as an external process is worth it only 
so that it can read an XML file and update a couple of tags.





More information about the Kimchi-devel mailing list