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. > (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 _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
