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.