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

[John Levon]

On Tue, Jul 08, 2008 at 09:21:11PM +0000, David Lutterkort wrote:

> > > > 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.
> > 
> > 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.
> 
> As far as this patch is concernd, ACPI and APIC can be requested in the
> virt-image XML; and clock and USB tablet should probably be added to it.
> The clock setting is a little weird, but I can imagine scenarios where
> that's not really a deployment specific option (or one that sets a
> default that can be overridden)

It's not just about these particular options, it's a general thing.

Whilst I agree that the virt-image route is the right one for most
cases, and I expect us to use it for most things, it doesn't make sense
for a conversion tool to purposefully throw away useful information.

A concrete example: several hypervisors can make use of qemu char device
specs (putting the serial console on a particular port for telnet, for
example). Without direct output, we'd throw that information out.

Now, there are a lot of use cases where we *don't* care about that
stuff, and that's great: we have virt-image as the default output format
for that.

Furthermore, the more of these things you add, the more you'll find
yourself with non-agnostic XML. Today, for example, the ACPI/APIC
settings are already host-specific (apic=1 kills a UP Solaris domU, but
presumably not on VMWare, maybe not on kvm, etc.).

> > And finally, there is currently no way to generate image XML from a
> > domain config (AFAIK). 
> > So we want this for libvirt import anyway.
> 
> Are you talking about a libvirt -> VMWare etc. conversion

That, plus building templates based on existing domUs etc. For example,
if I bring a dom0 under the control of oVirt (or whatever), I most
definitely want to dig out virt-image format descriptions of each of the
domUs.

Hope that makes my thinking on this a little clearer.

regards,
john