qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store co


From: Avi Kivity
Subject: Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
Date: Sun, 19 Aug 2007 13:35:54 +0300
User-agent: Thunderbird 2.0.0.0 (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
machine.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]