FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora/Linux Management Tools

 
 
LinkBack Thread Tools
 
Old 07-14-2008, 07:21 PM
Cole Robinson
 
Default virt-convert: Add "virt-instance" formatter

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

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 07-14-2008, 08:49 PM
Cole Robinson
 
Default virt-convert: Add "virt-instance" formatter

John Levon wrote:
>
>>> 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.
>

Like I mentioned above, virtinst is pretty crufty. Anything we have
hardcoded that is available via capabilities xml is a bug: unfortunately
virtinst pre-dated capabilities xml. If we have the option to start
from scratch, avoiding the hardcoding approach is definitely the way
to go, and only more motivation to fill out capabilities in libvirt

> 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 think a libvirt connection will only be necessary when converting TO
libvirt xml. If the input format is libvirt xml, we shouldn't need a
connection, since there really won't be anything we can gain from it.

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.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 07-14-2008, 09:11 PM
Cole Robinson
 
Default virt-convert: Add "virt-instance" formatter

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



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 

Thread Tools




All times are GMT. The time now is 09:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org