Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images

[Anthony Liguori]

Christian Brunschen wrote:
> On 11 Aug 2007, at 19:06, Philip Boulain wrote:
>
> > Yikes. I like the intent, but the idea of a previously just-data file 
> > format suddenly being able to imply "-hdb fat:rw:/home/" does not 
> > strike me as a good one. :/
>
> Hi all,
>
> I'm nobody in particular in the world of qemu, and have certainly 
> never contributed to it, but I hope you won't mind if I mention some 
> thoughts.
>
> It seems to me that overloading a simple data format to suddenly also 
> include metadata is indeed a decision fraught with potential for 
> unhappiness.
>
> Much better would be to perhaps devise a container format that would 
> embed a qemu configuration as well as a number of disk image files. Of 
> course, to have such ini a single file is not necessarily very easy. 
> However, one need only look at NeXTSTEP/OPENSTEP/Mac OS X to see a 
> solution: use a directory.

I expect we'll see something like this emerge in the future.

Regards,

ANthonY Liguori

> Basically, one way to bundle a machine configuration together yet 
> leave existing file formats unchanged is to define a standard 
> directory structure that can contain a qemu configuration file (a set 
> of command line options) as well as a number of related files (mainly 
> disk images, but could also me BIOS ROM or similar of course). It 
> doesn't need to be a complex structure: simply specify that a 'qemu 
> machine directory' contains a file named 'config.qemu' in a specific 
> format (with file references relative to the directory containing 
> config.qemu). qemu, if given as its sole command line option the name 
> of a directory, checks whether the directory contains a suitable 
> config.qemu, and reads & process the file as if it were command line 
> options (with the current directory.
>
> Such a directory can be kept entirely platform independent, such that 
> the entire directory could be moved or copied from one host to 
> another. It would mean perhaps tar:ing or zip:ing it up, but certainly 
> on Mac OS X such directories have proven to be a successful way of 
> bundling things together (certainly helped by the widespread use of 
> disk image files, through which distributing directories becomes 
> entirely a non-problem).
>
> Something like that _should_ offer most of the features that people 
> want - a simple way to encapsulate both configuration and data, 
> platform-independent, short and sweet to specify on the command line, 
> without making any changes to existing file formats (particularly disk 
> image ones).
>
> Just a thought,
>
> // Christian Brunschen