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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel