[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store co
Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
Sun, 19 Aug 2007 13:35:54 +0300
Thunderbird 220.127.116.11 (X11/20070419)
Christian Brunschen wrote:
On 17 Aug 2007, at 13:40, Avi Kivity wrote:
It's not easy to use: if you move the image, you need to move the file.
I'd like to have exactly one entity to worry about when using a virtual
As I wrote previously, there is already such a thing on every modern
operating system, one entity that can be used to wrap several others:
it's a directory. Putting things together into a directory, and then
treating that directory as a single entity, is a tried and tested
technique (in particular in NeXTStep and its successors, up to and
including Mac OS X).
Simply put, I think that it makes excellent sense to keep the data
(disk image) and the metadata (qemu configuration) separate, at least
in this particular case where keeping the data separate makes it more
easily reusable. Specifically, disk images that are simply disk images
are much more likely to be usable by more than one emulator / virtual
machine, than some other file format that combines a disk image with
some metadata that is going to be fundamentally non-portable and
indeed specific to one emulator or vm.
As I see it, the easiest and most portable thing to do is to define a
simple file format that qemu can use for its configuration. Place the
configuration file and the associated disk image(s) together in the
same directory, and you have created a single entity that includes
both the data and the metadata. Add a little bit of functionality to
the emulatir, such that if it is given as a suitable argument the name
of a directory, then look for the configuration file at a specific
name in that directory, and only allow references from that config
file to other files in that directory (thus enforcing the
encapsulation). Now you have a system where you can either keep things
completely manual (specify everything on the command line, automated
but separate (specify the configuration file and have it explicitly
reference full paths) or automated and encapsulated (data and metadata
all kept together in a single container). And all of this without
having to change the formats of any existing files, all without
introducing any backwards incompatibility.
It does make a lot of sense. The only drawbacks I can find are:
- you can't directly execute the directory
- this deviates from standard Unix (and Windows) practice. Arguably the
OS X way is superior, but qemu is perhaps not the best vehicle to
introduce it to other OSes.
While this implementation won't be my first choice, I find it acceptable
and good enough for my use case.
error compiling committee.c: too many arguments to function