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

[Cole Robinson]

John Levon wrote:
> On Mon, Jul 14, 2008 at 04:49:51PM -0400, Cole Robinson wrote:
> 
> 
>> 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.
> 
> Speaking generally, the problem that requires a connection for libvirt
> format applies to various other formats. If we're OK hacking around for
> those other formats, why not libvirt? It seems a little strange to be
> very picky for libvirt but not other formats.
> 

The reason we are picky with libvirt is because we _can_be_. Point me at
an alternative for hardcoding defaults for other formats and we can
consider them. I'm comparatively ignorant on the amount of ways a vmx
file can work on one machine and fail on another. Perhaps the sensible
solution is to require the host to have a full fledged vmware setup to
convert _to_ that format.

The difference is really small: say I'm on a xen host and want to convert
a xen machine to vmware. If we DONT require an active vmware connection/
setup, then we run virt-convert on the xen config, reboot into regular
kernel/vmware, and run the converted config.

The other way: start on xen, dump the config to a file. Reboot into vmware,
run virt-convert on the xen config to convert to vmx, then import.

If we have the means, I would definitely say go with version 2, since
the info we can glean from the active connection will reduce maintainance
burden and produce more accurate results. Someone would probably be
pretty pissed if they converted, rebooted, tried to run the config
and it failed.

So in actuality, the warning about 'this config will only work for
this host/connection' may very well apply to vmx exports as well.
I'm just not familiar enough with the format to say for sure.

- Cole