[et-mgmt-tools] Idea/help with virt-clone?

[Michael DeHaan]

Cole Robinson wrote:
> Michael DeHaan wrote:
>   
>> Cole Robinson wrote:
>>     
>>> Michael DeHaan wrote:
>>>   
>>>       
>>>> Here's something I would like to see, but do not know how to cleanly 
>>>> accomplish:
>>>>
>>>> virt-clone -o GUESTNAME -f NEWDISKFILE -x NEWXML
>>>>
>>>> The idea here is I really want to be able to clone guests, but I don't 
>>>> necessarily want to clone them on the same host.  Instead, I want to be 
>>>> able to track a central library of guests (and their associated disk 
>>>> images) in cobbler that I can clone later -- in my case, koan will be 
>>>> just doing the bare-minimum to get the virt-image parameters right to 
>>>> feed to virt-image.  So, in order to do this, I also need to get some 
>>>> XML out of the guest that is compatible with virt-image, so I can save 
>>>> it on the central server.
>>>>
>>>> The problem I have now is that the XML coming out of virsh dumpxml is 
>>>> not compatible with virt-image.
>>>>
>>>> This "-x" output would need to be in virt-image format and it would 
>>>> write this XML in addition to the diskfile.
>>>>
>>>> For example, once established, I could just feed this back into 
>>>> virt-image like so:
>>>>
>>>> virt-image foo.xml --n NEWNAME -u NEWUUID -m NEWMAC -b NEWBRIDGE
>>>>
>>>> I do not think I'm familiar with virtinst internals to add this, though 
>>>> it's something we are going to eventually need for ovirt.
>>>>
>>>> You can see a bit of what syntax I'm getting at (and the general idea) here:
>>>>
>>>> https://fedorahosted.org/cobbler/wiki/KoanWithIsos
>>>>
>>>> Though in addition koan would be tracking the xmlfile for cloning info 
>>>> as well.
>>>>
>>>>     
>>>>         
>>> I think the premise is okay, but from an app separation point
>>> of view it should be achieved a bit differently.
>>>
>>> We could add an option to virt-clone to output the libvirt xml of
>>> the new guest. This would be pretty simple to add.
>>>
>>> We could then use the new virt-convert tool to convert libvirt xml
>>> to virt-image xml. This functionality isn't present but work is
>>> being done in this area and would not be all that difficult to
>>> add.
>>>
>>> This adds an extra step to your proposed process, but I think is
>>> the sensible way to go. Converting libvirt xml to virt-image xml
>>> is desired functionality anyways, so we want to head in this
>>> direction.
>>>
>>> - Cole
>>>
>>>
>>>
>>>   
>>>       
>> Cool.
>>
>> Just to be sure we're on the same page, do you see this process looking 
>> something like:
>>
>> virt-clone guestname --dumpxml foo.xml --disk bar.disk && virt-convert 
>> --input foo.xml --dumpxml baz.xml
>> cp bar.disk /some/nfs_mounted/path/bar.disk
>> cp foo.xml /some/nfs_mounted/path/foo.xml
>> cobbler image --name=blip add --disk nfs://.../bar.disk --xml 
>> nfs://.../foo.xml
>> koan --server=cobbler.example.com --image=blip --virt
>>
>>     
>
> Yeah as far as I can imagine that seems about right.
>
>   
>> The koan command, when run:
>>
>> (a) copies the xml file from NFS to some directory
>> (b) copies the disk from NFS to some directory
>> (c) performs minimal xml surgery to fix up path URLs and replace any mac 
>> addresses the best it can using mac info stored in cobbler or randomly 
>> generated
>>     
>
> Actually the nature of the virt-image format is that you shouldn't
> need to do any xml surgery, it is (ideally) completely portable. Specific
> things like memory amounts and mac addresses are specified at the time
> virt-image is called: see virt-image --help for all the goodies that
> can be specified.
>
>   
That's even better. So it is possible to reuse --disk and --mac for 
multiple disks/macs, then?


>> (d) (if any overrides are in cobbler, like --virt-ram, it may also try 
>> to replace those, though those features are TBD and not really a concern 
>> in the ovirt case)
>> (e) runs virt-image against tweaked xml file.
>>
>> Sound good/close?
>>
>> --Michael
>>     
>
>