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.