Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

[Christian Brunschen]

On 3 Sep 2007, at 11:19, Philip Boulain wrote:

> On 1 Sep 2007, at 21:26, Jorge Lucángeli Obes wrote:
> > I think the problem here is that the scope of this change is not
> > clear. I _really_ wish to keep this simple. I _really_ wish to avoid
> > having giant command lines and useless shell scripts.
>
> Surely the small shell script /is/ the simple solution, as it  
> requires zero changes to QEMU itself.
>
> What's the difference between having to hack about a plain-text,  
> few-lines configuration file, and a plain-text, few-lines shell  
> script?

The same shells are not (at least by default) available on all  
platforms.

Basically, requiring a shell script means that you have to meta- 
program around qemu itself, whereas a configuration file means you're  
writing something within the context of qemu (and thus don't have to  
venture outside qemu's domain).

In my opinion, it would be nice, from the point of view of a user, to  
have this behaviour:

The command
        qemu foo
will behave as follows:
1) if 'foo' is a file:
  a) if 'foo' is a qemu configuration file (begins with a suitable,  
easily recognisable character sequence, read 'foo' as a configuration  
file; all relative path
    references within 'foo' will be interpreted relative to the  
current directory
  b) otherwise, use 'foo' as a disk image, presume a simple standard  
PC configuration, and attempt to boot from 'foo' as the disk image  
for ide0/hda
2) if 'foo' is a directory:
  verify that 'foo' is in fact a vm bundle directory, i.e., that it  
contains at the very least a qemu configuration file at a canonical  
name within the directory, i.e, 'qemu.cfg'. If there is no such  
configuration file, then the directory is _not_ a valid vm bundle,  
and qemu compains and exits. If the directory is a valid vm bundle,  
open and use the file 'qemu.cfg' inside the directory. All relative  
path references within 'qemu.cfg' will be interpreted relative to the  
'foo' directory, and no references outside the 'foo' directory will  
be permitted.

The qemu command also offers explicit command line options to specify  
with, say, '-c foo' that 'foo' is a configuration file, '-hda foo'  
that foo should be used as the ide0 hard drive image, and '-vm foo'  
that voo is a virtual machine bundle directory (containing both the  
configuration and any necessary resources - disk images, BIOS images,  
etc).

This gives the *user* of qemu the maximum ease-of-use, to simply  
invoke 'qemu' with a single point of entry, whether this single point  
is a hard drive image, a configuration file or a vm bundle directory.  
It costs very little implementation. It also means that programs like  
'Q' and such, while certainly nice, are not *necessary* to give the  
user a simple initial user experience for the simple use case of  
starting qemu. And it gives us the vm bundle format as an interchange  
format for moving virtual machines between qemu installations,  
including those that use *different* wrapper programs (like 'Q' and  
similar).

Saying that 'Q already handles this' means that any other program  
that wants to offer a similar ease-of-use would have to be able to  
read and interpret Q's configuration file format. If instead there is  
a wrapper-neutral format, then each wrapper can use that. Of course,  
each wrapper may also add its own, wrapper-specific information to  
its own bespoke configuration file within the bundle, but any  
information that is for qemu's use, and that can be shared regardless  
of which wrapper or even *if* a wrapper is used, would and should be  
kept in the qemu configuration file - making it possible and easy to  
share vm bundles with other people, whether or not they have or use  
the same wrapper.

> LionsPhil

Best wishes,

// Christian Brunschen