From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P) Date: Sun, 19 Aug 2007 13:35:54 +0300 Message-ID: <46C81D0A.8010009@qumranet.com> References: <21867471.1187283941478.JavaMail.root@eastrmwml26.mgt.cox.net> <46C5975A.6070906@qumranet.com> <5F34873A-05BE-4D91-8590-93898C7755CA@df.lth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org Return-path: In-Reply-To: <5F34873A-05BE-4D91-8590-93898C7755CA-HEm3bjczhZmzQB+pC5nmwQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/