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

[John Levon]

On Tue, Jul 08, 2008 at 09:32:49PM +0100, Daniel P. Berrange wrote:

> > > 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.

You're perfectly right, but I'm not trying to solve the general mobility
problem, nor is virt-convert. (If it were trying to do that, then there
wouldn't be a .vmx importer in the first place.)

> 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). 

Why is this an improvement over specifying stuff on the command line
(like --arch) ?

regards
john