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:36 PM
Bryan Kearney
 
Default virt-convert: Add "virt-instance" formatter

John Levon wrote:

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.


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.



--bk

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

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


_______________________________________________
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 03:44 AM.

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