[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Date: Mon, 13 Aug 2007 11:55:41 +0300
User-agent: Thunderbird (X11/20070419)

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

reply via email to

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