Re: [Qemu-devel] [PATCH] block: allow write-threshold on device name

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

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 member
>> (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 ("am
>> I about to exceed the allocation of my underlying storage?").  Likewise,
>> 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.
> 
> 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.

> 
> 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 to
> 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 <disk>, 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).

> 
> 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]