John Levon wrote: > >>> I'm a bit unclear on the need for this to be a requirement. It just >>> seems to be placing unnecessary obstacles in the user's way. You're >>> basically turning the warning above into an error for many situations. >> If we don't require using an active libvirt connection, we will find >> ourselves just duplicating information that is already presented by >> libvirt capabilities xml, such as emulator paths, feature availability >> like pae, and in the future, whitelists for device models, all with >> varying degrees of accuracy. > > Hmm. I don't think that's a big deal now at all (since virt-install is > already encoding all this stuff *anyway*). But I thought about it, and > you're right. This could become very tricky in the future. > Like I mentioned above, virtinst is pretty crufty. Anything we have hardcoded that is available via capabilities xml is a bug: unfortunately virtinst pre-dated capabilities xml. If we have the option to start from scratch, avoiding the hardcoding approach is definitely the way to go, and only more motivation to fill out capabilities in libvirt :) > However, there's still a problem I'm not sure how to deal with: general > export. In this case we might not even be exporting to a format that > libvirt can even *deal* with, never mind one that's on the other end of > the connection. What do we do in this case? > > How can I export to .vmx without hard-coding some stuff based upon > command-line options? Do we require a connection for this, and try to > work out defaults based on the connection anyway? This is less > than ideal: consider the poor user who's not booted under Xen, and wants > to import his Xen VM into VMWare on that machine. > I think a libvirt connection will only be necessary when converting TO libvirt xml. If the input format is libvirt xml, we shouldn't need a connection, since there really won't be anything we can gain from it. So if this user has a libvirt domain xml file and wants to convert to vmware, we don't use a connection, and will have to use some hardcoded conversions and defaults for libvirt->vmx. That's fine since as far as I know there isn't a better alternative. - Cole _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
