From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IJMX3-0001Cq-57 for qemu-devel@nongnu.org; Fri, 10 Aug 2007 00:55:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IJMX1-0001CS-OT for qemu-devel@nongnu.org; Fri, 10 Aug 2007 00:55:28 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IJMX1-0001CP-Li for qemu-devel@nongnu.org; Fri, 10 Aug 2007 00:55:27 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IJMX1-0002yc-7V for qemu-devel@nongnu.org; Fri, 10 Aug 2007 00:55:27 -0400 Received: by rv-out-0910.google.com with SMTP id k15so2081341rvb for ; Thu, 09 Aug 2007 21:55:25 -0700 (PDT) Message-ID: <59abf66e0708092155t2e3cd5o32f23c018bed65af@mail.gmail.com> Date: Fri, 10 Aug 2007 01:55:25 -0300 From: "=?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?=" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Qemu-devel] Storing command line options in images 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 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. 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. 4- We could have configuration files associated with the host and guests. 4a- Embedded XML. 4b- Separate files. 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