From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2fjc-0004Uy-TW for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:08:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2fjY-0005Tr-GB for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:08:00 -0400 Message-ID: <557836A5.4070407@redhat.com> Date: Wed, 10 Jun 2015 07:07:49 -0600 From: Eric Blake MIME-Version: 1.0 References: <1433641131-24123-1-git-send-email-eblake@redhat.com> <55776A49.3000705@redhat.com> <20150610075729.GB4899@noname.str.redhat.com> In-Reply-To: <20150610075729.GB4899@noname.str.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6pUoJM8e810VBoqdLCclL2Jp9fw3WvREr" Subject: Re: [Qemu-devel] [PATCH] block: allow write-threshold on device name List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: fromani@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6pUoJM8e810VBoqdLCclL2Jp9fw3WvREr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/10/2015 01:57 AM, Kevin Wolf wrote: >> >> The statistic I'm interested in is the allocation of the block device >> (the host offset, aka wr_highest_offset 72482304 above), and NOT the >> usage pattern of the guest (the qcow2 protocol, wr_highest_offset >> 9129332224). But bdrv_lookup_bs() finds the qcow2 protocol layer, >> rather than the intended backing file layer; likewise, query-block is >> only reporting write_threshold for the protocol layer. >> >> I'm wondering if, when a device name is given rather than a node name,= >> it is safe to blindly follow the active layer down to its lowest membe= r >> (or error out if there are more than one lower members, as in quorum),= >> as that is the statistic that libvirt and upper layers really want ("a= m >> I about to exceed the allocation of my underlying storage?"). Likewis= e, >> on reporting, it is more useful to know the threshold of the backing >> layer if the qcow2 protocol layer does not have a threshold. I'm >> playing with that idea before submitting a v2. >=20 > That is indeed what you need in your specific use case. However, qemu > shouldn't try to guess what management tools really want. It should > provide a clean interface that allows management tools to express > themselves what they want. Well, I think that means I need to bite the bullet and teach libvirt to use node names before it can take advantage of this feature; at which point this idea of allowing a threshold on device name is no longer important. >=20 > The cleanest interface that I can think of is that you access exactly > the node whose name you specified. If we do any magic like going down > the chain (which chain? What do you do with things like quorum in the > path?), we make the interface inconsistent and if anyone really wants t= o > know the highest offset that the guest accessed on its virtual disk, it= > wouldn't even be possible any more because we said that that's not what= > a management tool is interested in. My problem here is that libvirt tracks only a single , but that disk has two potential node names that need tracking (both the qcow2 protocol, and the underlying file). Furthermore, operations like snapshot creation, drive-mirror, and active block commit can change what the active layer is, and thus need another node name. It would really make life easier if qemu could auto-assign node names (so that EVERY node has a name without libvirt having to invent two names per qcow2 file), and then give libvirt an easy way to query the node names in use (query-block should make it obvious what the full node-name tree is, so that libvirt can then pick out the node name it is interested in). >=20 > Let's stay away from such magic, as much as we can. libvirt can just > specify a node-name for the protocol layer and use that. Okay, I'll probably abandon this patch, then, but still work on something to make node names easier for libvirt to integrate with. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --6pUoJM8e810VBoqdLCclL2Jp9fw3WvREr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVeDalAAoJEKeha0olJ0NqDKcH/3UEGsUaneRUcQm5+SaOO7ll 5kCQEvyQH8v8vNalemnV70b+IIXIh2QUOcAkUOnKVsyDdXS4SRXWhg/ALCfsZ+rD LOLdKX5CppT9H4fUhlNpP7ditToSo2Whx5VcunhoRmd7qc+yTIwr91p2oxcSr2Ah Bl2J/eTWbidVcB0jY51Ta0OiSIhwV0UnfUvw0aDJAnaKtGJShmcNqI+CTA7Mlohy Owxj/a6/i023GFJFjula1kcnuxkReR7MLecTbErPdN7b7dyAhDAYPiDRx3YeLRns 693hKsvelt9jsmtoKJFtWQKT8AZVLzgl+32APdcgabMN6Ra9Qoa1Pfxj4BHK1A4= =l+yk -----END PGP SIGNATURE----- --6pUoJM8e810VBoqdLCclL2Jp9fw3WvREr--