[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Making qemu images executable (and store command line a
Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
Thu, 16 Aug 2007 00:52:51 +0100
> I've been giving some thought to Anthony's idea:
> 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:
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
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!