John Levon wrote:
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.
I agree.. I could see a 2 very common use cases:
1) I am running on hypervisorX, and I get an image for hypervisor Y
which I want to play with. I should be able to convert Y to X without
having Y running in my enterprise.
2) I am building appliances, and I want to support hypervisor Y. I
should be able to build for my internal X and then convert to Y.
--bk
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
