[et-mgmt-tools] [PATCH 05 of 11] Allow output in libvirt.rng format

David Lutterkort dlutter at redhat.com
Tue Jul 8 21:16:42 UTC 2008


On Tue, 2008-07-08 at 19:51 +0100, John Levon wrote:
> On Tue, Jul 08, 2008 at 06:45:57PM +0000, David Lutterkort wrote:
> 
> > > standalone without any libvirt connection. This means it is unable
> > > to get any hypervisor specific capabilities data to determine what
> > > the required OS / boot type options are.
> > 
> > The right approach then seems to use virt-convert to convert to
> > image.xml and use virt-image to fill in the  deployment specific bits,
> > even if the user thinks they are just converting a VM from one format to
> > another.
> 
> If you mean implementation-wise (i.e. virtinstance.py should just call
> out to virt-image), then I suppose that'd be OK, because you can use
> virt-convert cmdline options plus the parsed config to specify exactly
> what you need in virt-image.

It should even be possible to do this in-process - if there is anything
of interest left in the actual virt-image CLI driver that is needed, it
should just be moved into the virtinst/ 'API'

> If you mean the *user* should do this, then see my other mail.

I am losing tracks of mails in this thread - I *think* I know which one
you are referring to, and will reply to that.

What the right flow is, i.e. whether the user should get a libvirt XML
or image.xml depends on the specific use case. The work around
virt-pack/virt-convert initially came out of wanting to turn an
appliance (i.e., VM image) into an appliance usable with another virt
solution. Of course, the use case of importing a VMWare VM into a
libvirt-based hypervisor is extremely important, too, though whether
you're going from VMWare VM -> libvirt image -> libvirt VM or straight
from one VM to the other depends a lot on what the user is trying to do,
since VMWare does not distinguish between a VM image/template and an
instantiated VM.

David





More information about the et-mgmt-tools mailing list