From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P) Date: Thu, 16 Aug 2007 08:21:39 +0300 Message-ID: <46C3DEE3.3040909@qumranet.com> References: <59abf66e0708151552r6192f7e1he7ebe5bffd49525f@mail.gmail.com> <200708160052.51858.mark.williamson@cl.cam.ac.uk> Reply-To: qemu-devel@nongnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org To: Mark Williamson Return-path: In-Reply-To: <200708160052.51858.mark.williamson@cl.cam.ac.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Mark Williamson wrote: >> I've been giving some thought to Anthony's idea: >> >> http://kvm.qumranet.com/kvmwiki/Specs/StoringCommandLineInImage >> >> However, maybe I'm just too much on vacations, but I don't seem to >> come up with a nice way of doing this. Everything keeps coming back to >> creating a new 'container' image format and then implementing block >> layer functions that only add the number of sectors occupied by the >> command-line to the read and write calls made by QEMU, and then just >> relay those calls to the image-specific functions. That doesn't sound >> very efficient. >> =20 > > It's not necessarily that pretty, but I wouldn't have thought that addi= ng a=20 > simple offset to block operations will have a measurable performance im= pact=20 > (given the latencies involved in block accesses anyhow, and the amount = of=20 > data transferred each time). > > =20 Right. >> The '#!' trick works nice with scripts, but I don't see it playing >> very well with images. =BFComments? =BFPointers? >> =20 > > Well, it's not really necessary, but it would be darn cool :-) Another= cool=20 > (but admittedly twisted - get the brain soap ready!) thing to do would = be to=20 > statically link a qemu, and then include a virtual machine config and d= isks=20 > in a section of the elf file (inspired by glick:=20 > http://blogs.gnome.org/alexl/2007/08/07/experiments-with-runtime-less-a= pp-bundles/). =20 > So then you'd have an "executable" VM image which doesn't need a Qemu r= untime=20 > to be available. There are various variations you could do on this bas= ic=20 > premise in order to make the file you carry around less terrifyingly hu= ge! > =20 That would make the VM not transportable (think moving from an x86_64 host to an i386 host) and would tie it to a particular version of kvm userspace. > Anyhow, enough of my random ideas... I was thinking about container fo= rmats. > > I've missed some of the discussion, but wouldn't tar be an obvious choi= ce? It=20 > can expand easily out to a directory hierarchy containing config file a= nd=20 > multiple virtual disk files, there are standard tools that can manipula= te it=20 > and standard libraries that can be used by Qemu in order to get at the=20 > contents. Only problem I see with this approach is that sparse file ha= ndling=20 > might get a bit strange (using real sparse files vs using tar's=20 > represesntation of sparse files vs compatibility with tars that don't s= upport=20 > them!). > =20 Also it can't be used in-place, like Anthony's header or the metadata-in-snapshot idea. --=20 Do not meddle in the internals of kernels, for they are subtle and quick = to panic.