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