On Mon, Jul 14, 2008 at 03:21:03PM -0400, Cole Robinson wrote: > No, setup_install would not be neccessary. You could populate a > Guest object with all the data imported from another format, > and then call validate_parms and get_xml_config. This sounds good, I'll look at doing this. > > 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. 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. regards john _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
