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