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

[Laurent Vivier <Laurent.Vivier-6ktuUTfB/bM@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3411 bytes --]

Avi Kivity wrote:
> 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).

I know we are not in democracy, but if I can vote I'd like to vote to the idea
of Christian Brunschen...

We can modify qemu to test if the argument is a directory, if yes, it reads args
from file args in this directory and for security the disk image must be in the
same directory.

for instance, we have:

./pc1/
./pc1/args
./pc1/my_disk

and in ./pc1/args, we have "-hda my_disk"

and when we run "qemu pc1", it starts "qemu -hda ./pc1/my_disk"

I don't like the idea of the config file (when it is complex it is very hard to
have a correct one like for Xen or like for Xorg)

I don't like the idea of Anthony because it looks like a hack .

Laurent, the killjoy
-- 
------------- Laurent.Vivier-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel