From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: Storing command line options in images Date: Fri, 10 Aug 2007 20:14:03 +0300 Message-ID: <46BC9CDB.3080900@qumranet.com> References: <59abf66e0708092155t2e3cd5o32f23c018bed65af@mail.gmail.com> <46BC8C18.6020108@codemonkey.ws> 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 To: qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org Return-path: In-Reply-To: <46BC8C18.6020108-rdkfGonbjUSkNkDKm+mE6A@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 Anthony Liguori wrote: > 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. It's not as bad as that -- the user has to remember only option (or have = a qemu-trusted script that supplies the option). But I agree that the = feature is now much less compelling, and that the new option is needed. > >> 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. > For which use case? management-full or management-less? A managed system will want to supply arguments out of a central = database. For a management-less use case, the config file is a hassle. ------------------------------------------------------------------------- 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IJY44-000373-JK for qemu-devel@nongnu.org; Fri, 10 Aug 2007 13:14:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IJY3z-0002za-3c for qemu-devel@nongnu.org; Fri, 10 Aug 2007 13:14:19 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IJY3y-0002zP-RC for qemu-devel@nongnu.org; Fri, 10 Aug 2007 13:14:14 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IJY3y-0007Pk-9d for qemu-devel@nongnu.org; Fri, 10 Aug 2007 13:14:14 -0400 Message-ID: <46BC9CDB.3080900@qumranet.com> Date: Fri, 10 Aug 2007 20:14:03 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [kvm-devel] Storing command line options in images References: <59abf66e0708092155t2e3cd5o32f23c018bed65af@mail.gmail.com> <46BC8C18.6020108@codemonkey.ws> In-Reply-To: <46BC8C18.6020108@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm-devel@lists.sourceforge.net, =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= Anthony Liguori wrote: > 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. >> =20 > > I think if you have to add a new option, the base implementation is=20 > wrong. The whole point of this is to simplify things for the user and=20 > adding more weird options just makes things more complicated. It's not as bad as that -- the user has to remember only option (or have=20 a qemu-trusted script that supplies the option). But I agree that the=20 feature is now much less compelling, and that the new option is needed. > >> 4- We could have configuration files associated with the host and=20 >> guests. >> 4a- Embedded XML. >> 4b- Separate files. >> =20 > > This is a big effort but a config file is the right long term solution. > For which use case? management-full or management-less? A managed system will want to supply arguments out of a central=20 database. For a management-less use case, the config file is a hassle.