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.