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, 08:35 PM
John Levon
 
Default virt-convert: Add "virt-instance" formatter

On Mon, Jul 14, 2008 at 03:21:03PM -0400, Cole Robinson wrote:

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

This sounds good, I'll look at doing this.

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

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.

regards
john

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

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.

regards,
john

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

On Mon, Jul 14, 2008 at 04:36:03PM -0400, Bryan Kearney wrote:

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

For anything libvirt-supported, producing virt-image output would be the
/best/ way to deal with these use cases. But indeed, for anything
machine-specific Y, we will /have/ to have a non-connection backup.

My argument is essentially that it's silly not to have a backup approach
for libvirt too. If it becomes infeasible with device models or whatever
in the future we can do:

virt-convert: error: export of 'foo' in bar.xml requires a connection

regards
john

_______________________________________________
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 07:53 AM.

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