Re: [libvirt] [PATCH 3/3] qemu: bulk stats: add block allocation information

On 09/25/2014 06:06 AM, Peter Krempa wrote: > From: Francesco Romani <fromani(a)redhat.com&gt; > > Management software wants to be able to allocate disk space on demand. > To support this they need keep track of the space occupation of the > block device. This information is reported by qemu as part of block > stats. > > This patch extend the block information in the bulk stats with the > allocation information. > > To keep the same behaviour a helper is extracted from > qemuMonitorJSONGetBlockExtent in order to get per-device allocation > information. And this also sounds useful for my work on trying to add a flag for showing capacity information during dumpxml. > > Signed-off-by: Francesco Romani <fromani(a)redhat.com&gt; > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com&gt; > --- > src/libvirt.c | 6 +++ > src/qemu/qemu_driver.c | 27 +++++++++++++ > src/qemu/qemu_monitor.h | 1 + > src/qemu/qemu_monitor_json.c | 91 ++++++++++++++++++++++++++++++++++---------- > 4 files changed, 105 insertions(+), 20 deletions(-) > > diff --git a/src/libvirt.c b/src/libvirt.c > index aa83365..b078eed 100644 > --- a/src/libvirt.c > +++ b/src/libvirt.c > @@ -21656,6 +21656,12 @@ virConnectGetDomainCapabilities(virConnectPtr conn, > * unsigned long long. > * "block.<num>.errors" - Xen only: the 'oo_req' value as > * unsigned long long. > + * "block.<num>.allocation" - offset of the highest written sector > + * as unsigned long long. > + * "block.<num>.capacity" - logical size in bytes of the block device backing > + * image as unsinged long long. s/unsinged/unsigned/ > + * "block.<num>.physical" - physical size in bytes of the container of the > + * backing image as unsigned long long. > * > > +typedef enum { > + QEMU_MONITOR_BLOCK_EXTENT_ERROR_OK, > + QEMU_MONITOR_BLOCK_EXTENT_ERROR_NOPARENT, > + QEMU_MONITOR_BLOCK_EXTENT_ERROR_NOSTATS, > + QEMU_MONITOR_BLOCK_EXTENT_ERROR_NOOFFSET > +} qemuMonitorBlockExtentError; Prefer trailing commas in the enum. ACK. Border-line on whether 2 and 3 are a feature addition, or rounding out the completed implementation (and therefore a bug fix) of a feature already being introduced in 1.2.9. So I'll leave it up to you on whether to push or delay, if no one else chimes in.