From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Storing command line options in qcow2 images Date: Mon, 30 Jul 2007 11:36:19 +0300 Message-ID: <46ADA303.9060504@qumranet.com> References: <59abf66e0707292040j11c8b981mf7f793258e874400@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, Laurent Vivier , qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org To: =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= Return-path: In-Reply-To: <59abf66e0707292040j11c8b981mf7f793258e874400-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 Avi, hi all, > > = I believe that Laurent (copied) is also interested in this area. > I've started some (very minor) groundwork for this task. My idea was > to add an extra "annotation" field in qcow2 snapshots. In this way, a > snapshot can hold abitrary information; for example, command line > arguments. > > Before going any further, I wanted to validate the general idea with > the list. = I've copied qemu-devel as well. This can benefit qemu as much as kvm = and I see no reasons that this shouldn't be merged into kvm through qemu = upstream. Furthermore, I'd very much hate to see qemu and kvm image = formats diverge, so I'd like to get the qemu maintainer's approval for = any format changes or extensions. > I am planning on using a snapshot with a distinct name to > store command line options. This approach seems simple yet it is > powerful enough for what we need to do. > = Yes, that seems to be the best idea. A snapshot name perhaps beginning = in a '\0' would avoid any ambiguity (much like the separate unix domain = socket namespace). > There's a slight overhead as now all qcow2 snapshots have to store a > extra (probably) empty pointer. An alternative approach would be to > somehow indicate that some snapshots are "descriptive" snapshots and > others are "useful" snapshots; however, I felt that this would be more > complicated. > = Will storing an extra pointer break existing qcow2 images? If so, we'd = better avoid it. > I have a working patch to qemu-img that allows storing arbitrary > annotations into qcow2 images. I developed it as a testing utility. > Right now annotations are implemented as another string alongside the > snapshot's 'name' and 'id'. I thought about storing annotations as > key/value pairs but again, it seemed overkill. > > >From here, the plan would be to add a command to qemu-img that allows > embedding of command line options into qcow2 images. These options > would be stored in a snapshot with a special name, and qemu would > check for the presence of this snapshot in order to read command line > options from the qcow2 image. > > Ideas? Suggestions? I can send the patches for the functionality > that's implemented right now. > = -- = error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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 1IFQjr-0006EH-Ow for qemu-devel@nongnu.org; Mon, 30 Jul 2007 04:36:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IFQjr-0006E5-3w for qemu-devel@nongnu.org; Mon, 30 Jul 2007 04:36:27 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IFQjr-0006E2-0p for qemu-devel@nongnu.org; Mon, 30 Jul 2007 04:36:27 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IFQjq-0006WX-7v for qemu-devel@nongnu.org; Mon, 30 Jul 2007 04:36:26 -0400 Message-ID: <46ADA303.9060504@qumranet.com> Date: Mon, 30 Jul 2007 11:36:19 +0300 From: Avi Kivity MIME-Version: 1.0 References: <59abf66e0707292040j11c8b981mf7f793258e874400@mail.gmail.com> In-Reply-To: <59abf66e0707292040j11c8b981mf7f793258e874400@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [kvm-devel] Storing command line options in qcow2 images Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= Cc: kvm-devel@lists.sourceforge.net, Laurent Vivier , qemu-devel@nongnu.org Jorge Luc=E1ngeli Obes wrote: > Hi Avi, hi all, > > =20 I believe that Laurent (copied) is also interested in this area. > I've started some (very minor) groundwork for this task. My idea was > to add an extra "annotation" field in qcow2 snapshots. In this way, a > snapshot can hold abitrary information; for example, command line > arguments. > > Before going any further, I wanted to validate the general idea with > the list.=20 I've copied qemu-devel as well. This can benefit qemu as much as kvm=20 and I see no reasons that this shouldn't be merged into kvm through qemu=20 upstream. Furthermore, I'd very much hate to see qemu and kvm image=20 formats diverge, so I'd like to get the qemu maintainer's approval for=20 any format changes or extensions. > I am planning on using a snapshot with a distinct name to > store command line options. This approach seems simple yet it is > powerful enough for what we need to do. > =20 Yes, that seems to be the best idea. A snapshot name perhaps beginning=20 in a '\0' would avoid any ambiguity (much like the separate unix domain=20 socket namespace). > There's a slight overhead as now all qcow2 snapshots have to store a > extra (probably) empty pointer. An alternative approach would be to > somehow indicate that some snapshots are "descriptive" snapshots and > others are "useful" snapshots; however, I felt that this would be more > complicated. > =20 Will storing an extra pointer break existing qcow2 images? If so, we'd=20 better avoid it. > I have a working patch to qemu-img that allows storing arbitrary > annotations into qcow2 images. I developed it as a testing utility. > Right now annotations are implemented as another string alongside the > snapshot's 'name' and 'id'. I thought about storing annotations as > key/value pairs but again, it seemed overkill. > > >From here, the plan would be to add a command to qemu-img that allows > embedding of command line options into qcow2 images. These options > would be stored in a snapshot with a special name, and qemu would > check for the presence of this snapshot in order to read command line > options from the qcow2 image. > > Ideas? Suggestions? I can send the patches for the functionality > that's implemented right now. > =20 --=20 error compiling committee.c: too many arguments to function