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

[Cole Robinson]

John Levon wrote:
> On Mon, Jul 14, 2008 at 12:55:23PM -0400, Cole Robinson wrote:
> 
>> So I'm not generally opposed to this idea, however the way this patch
>> implements it is a massive duplication of the virtinst apis, so
>> NACK in this current form.
> 
> I'm not sure it's "massive". Are you saying I should be using
> setup_install, etc. to generate the XML? This will leave me with no
> ability to modify what gets created, unless I'm misunderstanding you.
> I admit I'm not very familiar with these APIs.
> 

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.

Truthfully, virtinst as an API is a mess: It's been built
incrementally from an interactive script that made xen
guests. I've been thinking alot recently about ways to
clean it up and really seperate all the pieces.

That aside, It's main functions are as a way to build libvirt
xml, and a way to simplify install processes like fetching
tree kernels, setting up disks for cdrom booting, etc.

In this case you would be ignoring all the install pieces
and just using the objects to build the xml.

> I don't want to use virt-image directly because of its
> information-losing properties.

I understand this, virt-image certainly isn't the thing to use
unless portability is the specific goal.



>> Like Dan mentioned before, if we allow converting to libvirt xml, we
>> need to make it clear that the generated config is really only
>> applicable on the machine it is generated.
> 
> Surely, only applicable to machine it's generated on OR the connection it's
> connected to, if one's provided?
>

Yes my statement was unclear, I meant to say "only applicable for the
host the libvirt connection is on."
 
 
>> A connection must be required in order to do the conversion so we can
>> use the virtinst apis and check capabilities xml.
> 
> 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.

Also, what is the usecase of converting to libvirt xml _without_ an
active connection? If, lacking a connection, the best we can guarantee
is "this xml will work on this physical machine", then the xml would
only be useful if they have a libvirt setup on that physical
machine, and if that's the case they can provide a uri to the app.

Granted, having to specify a uri is annoying for a user, but we can
choose sensible defaults and make this largely transparent, as
virt-install currently does.


> (Yes, I know I don't have a connection option yet, hopefully I'll be
> adding this soon.)
> 
> regards
> john
> 

Thanks,
Cole