[libvirt] [PATCH 0/3] Get the voldef target physical value

[Michal Privoznik]

On 13.12.2016 22:07, John Ferlan wrote:
> This effort started primarily to address some ideas/thoughts brought
> up in https://bugzilla.redhat.com/show_bug.cgi?id=1332019 although as
> things were updated, it seems that using storage volume definitions
> wouldn't be necessary since the same data can be obtained via the
> virDomainGetBlockInfo API.
> 
> Still since code had been written - I figured I'd posted it and see
> what kind of feedback it got.
> 
> The first patch just adds the <physical> element to the output XML
> and documents it thusly.
> 
> The 2nd/3rd patch take a different approach adding virStorageVolInfoFlags
> which could take a single flag indicating that the caller would prefer
> to return the "physical" value instead of the "allocation" value. Yes,
> kind of a hack, but since we cannot extend _virStorageVolInfo to add
> a physical it's a mechanism to allow fetching the data using existing
> structures. Sure a virStorageVolStats API could be created as well,
> but I figured I'd see how this went first before thinking about that.
> 
> John Ferlan (3):
>   conf: Display <physical> in output of voldef
>   storage: Introduce virStorageVolInfoFlags
>   virsh: Allow display of the physical volume size
> 
>  daemon/remote.c                   | 38 +++++++++++++++++++++++++++++
>  docs/formatstorage.html.in        |  5 ++++
>  include/libvirt/libvirt-storage.h | 11 +++++++++
>  src/conf/storage_conf.c           |  6 +++++
>  src/driver-storage.h              |  6 +++++
>  src/libvirt-storage.c             | 51 +++++++++++++++++++++++++++++++++++++++
>  src/libvirt_public.syms           |  5 ++++
>  src/remote/remote_driver.c        | 37 ++++++++++++++++++++++++++++
>  src/remote/remote_protocol.x      | 20 ++++++++++++++-
>  src/remote_protocol-structs       | 10 ++++++++
>  src/storage/storage_driver.c      | 24 +++++++++++++++---
>  tools/virsh-volume.c              | 37 +++++++++++++++++++++++++---
>  tools/virsh.pod                   |  8 ++++--
>  13 files changed, 247 insertions(+), 11 deletions(-)
> 

Looks good. ACK. BUT see my comment to 3/3 before pushing - it needs a
bit of fixing.

Michal