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

Cole Robinson crobinso at redhat.com
Thu Oct 9 16:23:13 UTC 2008

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?

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

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

- separate tool, something like virt-import? would duplicate
  all the option parsing, but probably the cleanest solution.

I'd have to look at it all a bit more and determine what it
would really require to build up virt-image xml and how the
options would differ from a subset of virt-install options to
make an informed decision.


More information about the et-mgmt-tools mailing list