[et-mgmt-tools] RFC On importing raw images

Daniel P. Berrange berrange at redhat.com
Thu Oct 9 19:55:59 UTC 2008

On Thu, Oct 09, 2008 at 12:23:13PM -0400, Cole Robinson wrote:
> Bryan Kearney wrote:
> > We are starting to look at more interesting use cases around bringing in 
> > existing appliances into virt-manager. Joey has some interesting 
> > questions about driver, but I wanted to bring up an easier one.
> > 
> > Some of public appliances which exist are raw disk images which can 
> > easily be booted, but have no virt-image xml file. The user can of 
> > course manually create the file, but I think it would be nice to have 
> > the tooling help this. I could see one of the following solutions. Can 
> > folks pipe in with comments on these or another approach?
> >  
> > (1) Create an "interactive" mode for virt-image which prompts the user.
> Interactive shouldn't be our first goal, if a goal at all. We
> should design for the command line options and build a cli
> wizard as an afterthought.
> > (2) Modify virt-image to allow for all data normally the xml to be 
> > passed at command line (example, add a --imagefile parameter)
> > (3)Create a simple pre-processor to achieve 1 or 2 above.
> > 
> Hmm, the whole problem of taking an existing disk image and
> turning into something useful is not handled well by any of
> the virt-* tools.
> There needs to be an explicit way using one of the tools to
> say 'Don't install anything on this, just build an xml file
> with these options'. In turn there could be a flag to dump
> out libvirt xml or virt-image xml.
> The main problem is, where do we do this?

It really isn't all that much different from the live cd case
where there's no installer either - in fact the live cd
installer class in virtinst can basically do 90% of the 
neccessary stuff already - just doesn't need to bother with
adding a CDROM device.

> - virt-install: Seems the only option for libvirt xml, if
>   we want to define and start the guest. But what about just
>   dumping out the xml? Seems like it may be getting a bit
>   too ambitious. There are lots of virt-install options that
>   don't map well to virt-image, though we could just build
>   the xml and feed it through a libvirt xml -> virt-image
>   parser in virt-convert.

How about just adding a '--preinstalled' flag, handled in the
same way as --livecd, just causing it to skip install phase
and boot it straight off.

This could work in virt-manager too - in the wizard step where
you select  install source. You currently chose network install
source, PXE, or local media. Simply add a fourth 'pre-installed'.
All the rest of the wizard steps still apply, so we'd want to
share all that.

> - virt-image: no go for libvirt xml, but could be expanded
>   to build image xml, and probably the most consistent place
>   to do it.

Yeah, I don't think its applicable for virt-image. virt-image
is really focused on having all the domain metadata upfront 
and not prompting the user for it.

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

More information about the et-mgmt-tools mailing list