Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Christian Brunschen]

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.

One thing that would be useful would be if there were some portable  
way of describing the machine you are trying to virtualize or  
emulate. This could then be read by various different virtual  
machines / emulators. Such a portable description might be possible  
to embed in a disk image. However, it would take some doing to  
construct such a standard and indeed get it accepted by a significant  
fraction of the emulators / virtual machines in the marketplace today.


So to summarize, my preferred solution would be:
1) Define a configuration file format
2) Make the program allow specifying a directory as the virtual  
machine, in which case the configuration is read from and data are  
kept in that directory


Best wishes,

// Christian Brunschen