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/