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