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/