From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOE4V-0002jn-UZ for qemu-devel@nongnu.org; Thu, 13 Mar 2014 18:25:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOE4Q-0000B0-UZ for qemu-devel@nongnu.org; Thu, 13 Mar 2014 18:25:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOE4Q-0000AU-Mc for qemu-devel@nongnu.org; Thu, 13 Mar 2014 18:25:46 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2DMPjeo028601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Mar 2014 18:25:45 -0400 Message-ID: <53223068.1060001@redhat.com> Date: Thu, 13 Mar 2014 16:25:44 -0600 From: Eric Blake MIME-Version: 1.0 References: <5320C1DA.6010802@redhat.com> <5320C6A5.3090100@redhat.com> <5320EEF9.3020509@redhat.com> <5321CE26.70703@redhat.com> In-Reply-To: <5321CE26.70703@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="snK4Jc2N1AK5xwENOn7APC7ttLfq2gQ8M" Subject: Re: [Qemu-devel] [libvirt] RFC: Exposing backing chains in XML List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Krempa , "libvir-list@redhat.com" Cc: "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --snK4Jc2N1AK5xwENOn7APC7ttLfq2gQ8M Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [adding qemu-devel] Background to those new to the thread: Previously, libvirt has been tracking a lot of disk tunables alongside the active layer of a backing chain, without regards to any backing files in the chain. However, now that qemu supports named BDS nodes anywhere in the backing chain, I'm realizing that libvirt needs to track the entire backing chain in its XML for maximum control over each qemu BDS. On 03/13/2014 09:26 AM, Eric Blake wrote: > In making the proposed split, I noticed that we've abused the > element to contain a hodgepodge of things that are per-device (for > example, cache is a per-device setting, while format is a per-file > setting), so I'm now trying to figure out how to tweak the XML to > express the difference. I may end up keeping only at the top > level, and adding a new subelement inside , then= > for back-compat reasons duplicate and = at > the top level, or teaching the disk source formatter to merely append i= n > a string of device-level attributes when formatting the active disk of > the chain. Among other things, libvirt can append the following to a -drive command-line option: cache=3D aio=3D rerror=3D werror=3D discard=3D sgio=3D bps=3D =2E.. Looking in the schema file, BlockdevOptionsBase supports many of this options on a per blockdev basis. Does that mean that libvirt should allow for a different rerror=3D on a backing file than it does for the active file? Similarly for cache=3D or discard=3D? Or are some of these= options really only sensible at the active layer, belonging more to the -drive than to each backing BDS within the drive? Knowing which options belong where will help me partition the libvirt structure into attributes that are per-file vs. those that are per-device. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --snK4Jc2N1AK5xwENOn7APC7ttLfq2gQ8M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTIjBoAAoJEKeha0olJ0NqwWoIAIeCkcP45gbcCNf01X+rX9X1 Qe5SJpUtYoOAxQg93jbe8PdVasr9wf4XP616/84vbq9qWQKhBV1xE8ltTCgCHUhy 93byEN197QTAfPNLNB3jWtQwl5/coHrbXFwAs4LsKc9AByGmF6Ol9StzZVvJ35/n P5+bMs9wdLtVACxLtWVEeJqivj9OC0QgS7DBr3Ideg3k/EUO95mpr8hPOCorBtxg 4XI2k5yKIY9e+X+v5vGpYGVysnH06wXVrgnmTnP1msp8N2T02UP/MeWdVzhSy65B TjKP3azDvRlkcMGUAX0sHk1e5fLQYi5vQZjVQH48x+AR0rYAOyCAgwrziWzek4A= =5GCA -----END PGP SIGNATURE----- --snK4Jc2N1AK5xwENOn7APC7ttLfq2gQ8M--