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