qemu-devel
[Top][All Lists]
Advanced

[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: Fri, 17 Aug 2007 15:40:58 +0300
User-agent: Thunderbird 2.0.0.5 (X11/20070719)

Ben Taylor wrote:
> ---- "Jorge Lucángeli Obes" <address@hidden> 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.





reply via email to

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