[Kimchi-devel] [RFC] Guest cloning

Royce Lv lvroyce at linux.vnet.ibm.com
Thu Oct 9 08:11:31 UTC 2014


On 2014年10月07日 23:27, Christy Perez wrote:
> I'm guessing that Brent and Adam already discussed virt-clone, so I'm
> curious as to the reasons why that's not an option. I've found that
> virt-install (the package that includes it) has (on Fedora 20) a
> dependency on virt-manager-common. That, and maybe it's not available
> for all distros? Maybe it wouldn't copy disks into the right places?
>
> Thanks,
>
> - Christy
This is a good idea, I haven't used virt-clone, is it copy image or just 
make a cow of the base one?
For this scenario, we want a full copy or cow one?
>
> On 10/06/2014 08:28 AM, Crístian Viana wrote:
>> On Sex, 2014-10-03 at 08:28 -0500, Brent Baude wrote:
>>> At one point Adam had really suggested we look at how guests are defined
>>> and changed.  In particular, straight copies of XML and or straight
>>> edits of XML could lead (after time) to the XML digressing into
>>> something libvirt might not understand at some point.
>> Do you remember exactly what in the XML file digressed like that? It
>> would be very nice to know it.
>>
>>> To prevent this sort of problem, we thought that each time a guest is
>>> edited, the XML is created entirely anew but of course using the same
>>> values.
>> I first thought about doing that as well, but I'm afraid our own new XML
>> does not have all the features the original VM had. For example, on
>> Kimchi we don't have support to custom CPU flags yet (i.e. we don't
>> add/change those values). What would happen if we clone an existing VM
>> with "unsupported" (as of Kimchi) features like that one? If we don't
>> know about them and we're creating a new XML from scratch, we're only
>> going to add what we're aware of. And I think this could make our
>> cloning feature very unrealiable. Reading an existing XML and redefining
>> it will always propagate whatever there is in that VM. As long as the
>> XML doesn't get digressed, of course.
>>
>> Here's one current scenario for me. I have a few VMs on my laptop which
>> I use to test Kimchi on them. As they need to be a hypervisor in order
>> to run Kimchi, I have to add a few CPU flags to their XML descriptors
>> which allow them to be a hypervisor (i.e. those Intel/AMD virtualization
>> parameters). I do that manually using "virsh edit". If I clone one of my
>> VMs using the approach above and it recreates their XML files from the
>> beginning, AFAIU, the CPU flags will not be copied along. And I'd be
>> very unsatisfied because the clone feature dropped a few things of my
>> original VM while cloning.
>>
>> If we know what are the problems you had with Adam while copying the XML
>> files over and over, maybe it' easier to fix them than to try to create
>> a new one with all the libvirt's features, including the ones Kimchi is
>> still not aware of.
>>
>>> About a month ago I had a working version of this in draft
>>> form.
>>> Would anyone be interested in reviewing it and or adding to it prior to
>>> implementing the clone function?  If so, ping me on IRC and I'll get you
>>> a copy of the patch.
>> I am interested on it! I'll ping you then.
>>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel




More information about the Kimchi-devel mailing list