Re: Storing command line options in images

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

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.

Regards,

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.
>
> Cheers,
> Jorge
>
> -------------------------------------------------------------------------
> 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
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


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