[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store co
From: |
Avi Kivity |
Subject: |
Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P) |
Date: |
Thu, 16 Aug 2007 08:21:39 +0300 |
User-agent: |
Thunderbird 2.0.0.5 (X11/20070719) |
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.
>>
>
> 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).
>
>
Right.
>> 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!
>
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 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!).
>
Also it can't be used in-place, like Anthony's header or the
metadata-in-snapshot idea.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.