qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Making qemu images executable (and store command line a


From: Mark Williamson
Subject: Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
Date: Thu, 16 Aug 2007 00:52:51 +0100
User-agent: KMail/1.9.6

> 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.

It's not necessarily that pretty, but I wouldn't have thought that adding a 
simple offset to block operations will have a measurable performance impact 
(given the latencies involved in block accesses anyhow, and the amount of 
data transferred each time).

> The '#!' trick works nice with scripts, but I don't see it playing
> very well with images. ¿Comments? ¿Pointers?

Well, it's not really necessary, but it would be darn cool :-)  Another cool 
(but admittedly twisted - get the brain soap ready!) thing to do would be to 
statically link a qemu, and then include a virtual machine config and disks 
in a section of the elf file (inspired by glick: 
http://blogs.gnome.org/alexl/2007/08/07/experiments-with-runtime-less-app-bundles/).
  
So then you'd have an "executable" VM image which doesn't need a Qemu runtime 
to be available.  There are various variations you could do on this basic 
premise in order to make the file you carry around less terrifyingly huge!

Anyhow, enough of my random ideas...  I was thinking about container formats.

I've missed some of the discussion, but wouldn't tar be an obvious choice?  It 
can expand easily out to a directory hierarchy containing config file and 
multiple virtual disk files, there are standard tools that can manipulate it 
and standard libraries that can be used by Qemu in order to get at the 
contents.  Only problem I see with this approach is that sparse file handling 
might get a bit strange (using real sparse files vs using tar's 
represesntation of sparse files vs compatibility with tars that don't support 
them!).

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!




reply via email to

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