[Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Jorge Lucángeli Obes]

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.

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

Cheers,
Jorge

Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Mark Williamson]

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

[Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P)

[H. Peter Anvin]

Jorge Lucángeli Obes wrote:
> 
> The '#!' trick works nice with scripts, but I don't see it playing
> very well with images. ¿Comments? ¿Pointers?
> 

Well, you can make it work with a header (you just have to pad it out to
a fixed length or use a variable-offset format), but binfmt_misc might
be a better choice.

	-hpa

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Avi Kivity]

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.

Re: [Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P)

[Avi Kivity]

H. Peter Anvin wrote:
> Jorge Lucángeli Obes wrote:
>   
>> The '#!' trick works nice with scripts, but I don't see it playing
>> very well with images. ¿Comments? ¿Pointers?
>>
>>     
>
> Well, you can make it work with a header (you just have to pad it out to
> a fixed length or use a variable-offset format), but binfmt_misc might
> be a better choice.
>
>   

binfmt_misc is Linux specific.  And while kvm is a Linux thing now, qemu
isn't.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P)

[Luke -Jr]

On Thursday 16 August 2007, H. Peter Anvin wrote:
> Jorge Lucángeli Obes wrote:
> > The '#!' trick works nice with scripts, but I don't see it playing
> > very well with images. ¿Comments? ¿Pointers?
>
> Well, you can make it work with a header (you just have to pad it out to
> a fixed length or use a variable-offset format), but binfmt_misc might
> be a better choice.

Can't hurt to support both, can it? ;)

Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Andreas Färber]

Am 16.08.2007 um 01:52 schrieb Mark Williamson:

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

Q uses the extension .qvm on an ordinary directory containing an XML  
configuration file and the image(s), so that double-clicking the  
directory opens the guest with Q. Can GNOME/KDE only do that for  
files so that an archive is necessary?

Andreas

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Avi Kivity]

Ben Taylor wrote:
> ---- "Jorge Lucángeli Obes" <t4m5yn@gmail.com> 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.
>>     
>
> No, and it fundamentally breaks using a real disk with QEMU.
>
>   

Why?  It's optional.

>> The '#!' trick works nice with scripts, but I don't see it playing
>> very well with images. ¿Comments? ¿Pointers?
>>     
>
> Personally, I'm not sure why we wouldn't just write out the command line
> data to a file tied to the primary image file, with some kind of time stamp
> to correlate the data from the command line and the last updated time
> of the primary image file.  It's intuitive, and doesn't require a bucket of
> programming to make work.  The down side is if qemu crashes, the
> time stamp between the parameter file and the image file may indicate
> the potential for "difference", but this can just be a notice (just as snapshots
> used to do with the image files in 0.7.x)
>   

It's not easy to use: if you move the image, you need to move the file. 
I'd like to have exactly one entity to worry about when using a virtual
machine.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Christian Brunschen]

On 17 Aug 2007, at 13:40, Avi Kivity wrote:

> It's not easy to use: if you move the image, you need to move the  
> file.
> I'd like to have exactly one entity to worry about when using a  
> virtual
> machine.

As I wrote previously, there is already such a thing on every modern  
operating system, one entity that can be used to wrap several others:  
it's a directory. Putting things together into a directory, and then  
treating that directory as a single entity, is a tried and tested  
technique (in particular in NeXTStep and its successors, up to and  
including Mac OS X).

Simply put, I think that it makes excellent sense to keep the data  
(disk image) and the metadata (qemu configuration) separate, at least  
in this particular case where keeping the data separate makes it more  
easily reusable. Specifically, disk images that are simply disk  
images are much more likely to be usable by more than one emulator /  
virtual machine, than some other file format that combines a disk  
image with some metadata that is going to be fundamentally non- 
portable and indeed specific to one emulator or vm.

As I see it, the easiest and most portable thing to do is to define a  
simple file format that qemu can use for its configuration. Place the  
configuration file and the associated disk image(s) together in the  
same directory, and you have created a single entity that includes  
both the data and the metadata. Add a little bit of functionality to  
the emulatir, such that if it is given as a suitable argument the  
name of a directory, then look for the configuration file at a  
specific name in that directory, and only allow references from that  
config file to other files in that directory (thus enforcing the  
encapsulation). Now you have a system where you can either keep  
things completely manual (specify everything on the command line,  
automated but separate (specify the configuration file and have it  
explicitly reference full paths) or automated and encapsulated (data  
and metadata all kept together in a single container). And all of  
this without having to change the formats of any existing files, all  
without introducing any backwards incompatibility.

One thing that would be useful would be if there were some portable  
way of describing the machine you are trying to virtualize or  
emulate. This could then be read by various different virtual  
machines / emulators. Such a portable description might be possible  
to embed in a disk image. However, it would take some doing to  
construct such a standard and indeed get it accepted by a significant  
fraction of the emulators / virtual machines in the marketplace today.


So to summarize, my preferred solution would be:
1) Define a configuration file format
2) Make the program allow specifying a directory as the virtual  
machine, in which case the configuration is read from and data are  
kept in that directory


Best wishes,

// Christian Brunschen

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Avi Kivity]

Christian Brunschen wrote:
>
> On 17 Aug 2007, at 13:40, Avi Kivity wrote:
>
>> It's not easy to use: if you move the image, you need to move the file.
>> I'd like to have exactly one entity to worry about when using a virtual
>> machine.
>
> As I wrote previously, there is already such a thing on every modern 
> operating system, one entity that can be used to wrap several others: 
> it's a directory. Putting things together into a directory, and then 
> treating that directory as a single entity, is a tried and tested 
> technique (in particular in NeXTStep and its successors, up to and 
> including Mac OS X).
>
> Simply put, I think that it makes excellent sense to keep the data 
> (disk image) and the metadata (qemu configuration) separate, at least 
> in this particular case where keeping the data separate makes it more 
> easily reusable. Specifically, disk images that are simply disk images 
> are much more likely to be usable by more than one emulator / virtual 
> machine, than some other file format that combines a disk image with 
> some metadata that is going to be fundamentally non-portable and 
> indeed specific to one emulator or vm.
>
> As I see it, the easiest and most portable thing to do is to define a 
> simple file format that qemu can use for its configuration. Place the 
> configuration file and the associated disk image(s) together in the 
> same directory, and you have created a single entity that includes 
> both the data and the metadata. Add a little bit of functionality to 
> the emulatir, such that if it is given as a suitable argument the name 
> of a directory, then look for the configuration file at a specific 
> name in that directory, and only allow references from that config 
> file to other files in that directory (thus enforcing the 
> encapsulation). Now you have a system where you can either keep things 
> completely manual (specify everything on the command line, automated 
> but separate (specify the configuration file and have it explicitly 
> reference full paths) or automated and encapsulated (data and metadata 
> all kept together in a single container). And all of this without 
> having to change the formats of any existing files, all without 
> introducing any backwards incompatibility.
>

It does make a lot of sense.  The only drawbacks I can find are:
- you can't directly execute the directory
- this deviates from standard Unix (and Windows) practice.  Arguably the 
OS X way is superior, but qemu is perhaps not the best vehicle to 
introduce it to other OSes.

While this implementation won't be my first choice, I find it acceptable 
and good enough for my use case.

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Markus Hitter]

Am 19.08.2007 um 12:35 schrieb Avi Kivity:

> - this deviates from standard Unix (and Windows) practice.   
> Arguably the OS X way is superior, but qemu is perhaps not the best  
> vehicle to introduce it to other OSes.

NeXTstep introduced this into the Unix world and GNUstep uses it  
today. So, there's prior art.


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Avi Kivity]

Markus Hitter wrote:
> Am 19.08.2007 um 12:35 schrieb Avi Kivity:
>
>   
>> - this deviates from standard Unix (and Windows) practice.   
>> Arguably the OS X way is superior, but qemu is perhaps not the best  
>> vehicle to introduce it to other OSes.
>>     
>
> NeXTstep introduced this into the Unix world and GNUstep uses it  
> today. So, there's prior art.
>
>   

Nothing on my machine uses it today, as far as I can tell.

(I don't oppose this use in Linux -- I think it's an excellent way to 
package apps -- but I'm not sure qemu should be the first app to do 
this.  It needs buy-in from distros)

((but we're actually talking about something slightly different; 
packaging data vs packaging apps))

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Christian Brunschen]

On 19 Aug 2007, at 12:08, Avi Kivity wrote:

> Markus Hitter wrote:
>> Am 19.08.2007 um 12:35 schrieb Avi Kivity:
>>
>>> - this deviates from standard Unix (and Windows) practice.    
>>> Arguably the OS X way is superior, but qemu is perhaps not the  
>>> best  vehicle to introduce it to other OSes.
>>
>> NeXTstep introduced this into the Unix world and GNUstep uses it   
>> today. So, there's prior art.
>
> Nothing on my machine uses it today, as far as I can tell.
>
> (I don't oppose this use in Linux -- I think it's an excellent way  
> to package apps -- but I'm not sure qemu should be the first app to  
> do this.  It needs buy-in from distros)
>
> ((but we're actually talking about something slightly different;  
> packaging data vs packaging apps))

This has been the preferred way to package _any_ 'bundle' of data,  
whether it be an application, a framework, a rich-text file with  
images (the '.rtfd' format), since its introduction in NeXTStep, and  
ever since then it has been and remains the preferred way in  
OPENSTEP, Mac OS X, and GNUStep.

There is *ample* precedent, so qemu would not be the first app on  
Linux or on any other Unix either. Remember also that OpenStep was  
available for Solaris for a while, and that NeXT/Apple's WebObjects,  
which included a development environment and various applications,  
also ran on Solaris, HP-UX and even on Windows NT and 2000. So this  
NeXT/Apple-style bundling of related files into a directory which is  
then treated as a single unit has been used successfully on a wide  
variety of systems, including Linux and any other plaftorm that can  
run GNUStep, as well as various Unixen and Windows. And I am talking  
about this very much in the sense of packaging *data*, not 'just'  
applications.

So there is ample precedent, it is a successfully and widely used  
idea that has been previously successully used on multiple platforms,  
and in fact is the standard on the most widely used unix today (Mac  
OS X).

Plus, there's ample precedent for similar things: Many administrators  
keep various interconnected configuration files for (for instance)  
apache in a directory that is apache-configuration-specific,  
effectively treating 'apache configuration' as a single unit with  
multiple parts - the parts (configuration files for specific aspects)  
being bundled together in a directory to show the fact that they are  
a unit and do belong together.

Best wishes,

// Christian Brunschen