Re: [Qemu-devel] Re: Storing command line options in images

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Jorge Lucángeli Obes wrote:
>>> My feeling is that config files are outdated.  When used with a gui,
>>> you end up writing silly parsers and stuff and still wrecking things
>>> horribly when the the gui writer's expectations don't match reality.
>>> When used without a gui, they increase the amount of details one has
>>> to remember (where's that config file? I renamed my image, did I
>>> remember to update the config file?).  They also make upgrading more
>>> difficult.
>>>       
>> There's only so much that can be expressed on a command line.  There are
>> actually limits to the command line size on a lot of platforms.  I don't
>> see why reading options from a file is so much worse than reading them
>> from the command line.
>>     
>
> In my view, the bottom line is: we need an _easy_ way of launching VMs
> when one doesn't want all the options of the managed approach. I back
> Avi on this one, I would like to be able to do
>
> qemu guest.img
>   

Well, I disagree with Avi now.  Dan's comment about guest images now 
being untrusted is a killer.

> without worrying about configuration files, or XML, or parsing. That's
> not to say that a global configuration file for QEMU wouldn't be
> useful, but I think it would solve a different problem.
>
> When I read Avi's TODO, I basically thought about getting rid of the
> long command lines I had to store in scripts. I wanted to write that
> command line once, and then forgetting about it, until I needed to
> change it. I wanted an image to be self-contained as much as possible.
> That's what I set to achieve.
>
> All that said, I rethought Anthony's idea of storing plain text in the
> image and with proper tools, it can work out. I don't like the idea of
> having users overwriting and padding files, but the approach seems
> less of a hack than using empty snapshots. In short: I think we will
> need to have something like 'qemu-img cmdline' anyways, independent of
> the implementation. That's because I would like an implementation that
> does not depend on extra files. For that, we already have libvirt and
> the likes.
>   

I like the format-independent nature of Anthony's idea too.  Basically 
we're adding a meta-format that works along with all other formats.

Anthony's other idea, to require self-contained images to be executable, 
may be workable.  I have some doubts that it is a sufficient indicator 
of trust (though with normal shell scripts and executables it is).


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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/