[et-mgmt-tools] [PATCH 11 of 11] virt-convert: Add "virt-instance" formatter

[Cole Robinson]

Bryan Kearney wrote:
>> 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.

So if you download vmx and are on libvirt, you have an active connection
available which you can pass to virt-convert. If you are on vmware
and download libvirt, a connection won't be required for conversion
so this also would work fine.

> 
> 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.
>

>From the appliance perspective, portability is key. Unfortunately,
libvirt domain xml is not portable. So the case of converting TO
libvirt xml is not relevant here. So if you build a libvirt
domain, you can then export to vmx or virt-image format without
needing any special connections as mentioned above.

So I think requiring the libvirt connection for domain xml export
doesn't impede these use cases.

- Cole