[et-mgmt-tools] [PATCH 09 of 11] Add OS variant options to virt-convert

[Daniel P. Berrange]

On Tue, Jul 08, 2008 at 01:49:41PM +0100, John Levon wrote:
> On Tue, Jul 08, 2008 at 01:30:42PM +0100, Daniel P. Berrange wrote:
> 
> > > Add OS variant options to virt-convert.
> > > 
> > > And use them to set ACPI, APIC, clock, and USB tablet.
> > 
> > Again, I don't think libvirt domain XML should be handled by this tool
> > precisely because of the issues you're attempting to address here.
> 
> What do you mean "again" ?
> 
> libvirt is only part of the problem: it's not the only virt format with
> hypervisor specific settings. Even if you were to enforce the use of
> virt-image, you've still got the same problems if we ever want true
> mobility between other formats.

This isn't really solving the mobility problem though - its exchanging
one problem (a VMWare specific config file) for another equally bad
problem (a 32-bit Xen speciifc libvirt XML config). The virt-image
or OVF formats are the only two I'm aware of that achieve any degree
of mobility because they remove all instance specific metadata and
focus on the core requirements of a VM.

> Even worse, the image XML is very lossy. Whilst I imagine that
> virt-image will *typically* be used, enforcing an information-removing
> step doesn't make much sense to me.

It is delibrately lossy in many areas. It explicitly excludes info that
is fundamentally specific to a particular deployment of a VM. It fills
this info in at time of instantiation based on the capabilities XML
presented by the hypervisor being deployed onto. 

If we accept we want to use virt-convert to generate libvirt XML, then
we need to require a hypervisor connection URI for this conversion so
we can fetch the capabilities data and fill in the deployment specific
bits.  And the resulting libvirt XML generated will be specific to the
machine it was generated on (or another with equivalent setup). 

> And finally, there is currently no way to generate image XML from a
> domain config (AFAIK). So we want this for libvirt import anyway.

Yes, we do need a way to go from libvirt XML to virt-image XML, but this
is a far easier problem because we're not hardcoding hypervisor specific
data, rather we''re removing it.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|