On Tue, 2008-07-08 at 19:51 +0100, John Levon wrote: > On Tue, Jul 08, 2008 at 06:45:57PM +0000, David Lutterkort wrote: > > > > standalone without any libvirt connection. This means it is unable > > > to get any hypervisor specific capabilities data to determine what > > > the required OS / boot type options are. > > > > The right approach then seems to use virt-convert to convert to > > image.xml and use virt-image to fill in the deployment specific bits, > > even if the user thinks they are just converting a VM from one format to > > another. > > If you mean implementation-wise (i.e. virtinstance.py should just call > out to virt-image), then I suppose that'd be OK, because you can use > virt-convert cmdline options plus the parsed config to specify exactly > what you need in virt-image. It should even be possible to do this in-process - if there is anything of interest left in the actual virt-image CLI driver that is needed, it should just be moved into the virtinst/ 'API' > If you mean the *user* should do this, then see my other mail. I am losing tracks of mails in this thread - I *think* I know which one you are referring to, and will reply to that. What the right flow is, i.e. whether the user should get a libvirt XML or image.xml depends on the specific use case. The work around virt-pack/virt-convert initially came out of wanting to turn an appliance (i.e., VM image) into an appliance usable with another virt solution. Of course, the use case of importing a VMWare VM into a libvirt-based hypervisor is extremely important, too, though whether you're going from VMWare VM -> libvirt image -> libvirt VM or straight from one VM to the other depends a lot on what the user is trying to do, since VMWare does not distinguish between a VM image/template and an instantiated VM. David _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
