[Top][All Lists]

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

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

From: Anthony Liguori
Subject: [Qemu-devel] Re: [kvm-devel] Storing command line options in images
Date: Fri, 10 Aug 2007 11:02:32 -0500
User-agent: Thunderbird (X11/20070728)

Jorge Lucángeli Obes wrote:
Hi all,

>From what I've gathered, it seems that we have basically four options
at hand. I think it's important to notice, however, that whatever
comes out of this will probably be, as Avi said, a "low-end" solution.
IMHO there's room to have both the high-end libvirt-like approach, and
the "shell replacer" approach.

So let's see:

1- We could go the way of the patches I've posted, adding the comments
everyone's made.
1a- It's a good idea to actively signal QEMU to read command line
options from the image file, and not have it on by default.

I think if you have to add a new option, the base implementation is wrong. The whole point of this is to simplify things for the user and adding more weird options just makes things more complicated.

1b- As Avi said, there are many guest-related options that would be
good to store _somewhere_. The user always has the option of using
qemu-img to review the options that the VM is going to use. I think
that having a "valid" set of options that the user can store will
complicate things too much.

2- We could bump qcow's version number and add command line options as
"first-class citizens" of the image world.
2a- As Anthony suggested, it could be a good starting point to make
sure these version transition happen in a smoother way.

3- We could add command line options as plain text in the image
itself. Sounds (to me) risky and not very user friendly.

Why is it risky or user unfriendly? From the user's perspective, it's no different from storing it in a snapshot. The user still needs a separate tool (qemu-img) to view and manipulate the command line. The only real user facing difference is that the image itself is now directly executable. This turns out to be a Good Thing in that the user is now aware that he must trust that image which addresses the concern in 1a.

4- We could have configuration files associated with the host and guests.
4a- Embedded XML.
4b- Separate files.

This is a big effort but a config file is the right long term solution.


Anthony Liguori

What do you guys think? I'm partial to 1 or 2. Since the beginning my
approach was that of a simple solution for a simple feature.


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/
kvm-devel mailing list

reply via email to

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