From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Storing command line options in images Date: Fri, 10 Aug 2007 11:02:32 -0500 Message-ID: <46BC8C18.6020108@codemonkey.ws> References: <59abf66e0708092155t2e3cd5o32f23c018bed65af@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org To: =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= Return-path: In-Reply-To: <59abf66e0708092155t2e3cd5o32f23c018bed65af-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Jorge Luc=E1ngeli 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/