qemuDomainGetBlockInfo would error out if qemu did not report
'wr_highest_offset'. This usually does not happen, but can happen
briefly during active layer block commit. There's no need to report the
error, we can simply report that the disk is fully alocated at that
point.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1452045
---
 src/qemu/qemu_driver.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 67f54282a..f6b352b56 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -11541,14 +11541,6 @@ qemuDomainGetBlockInfo(virDomainPtr dom,
     }

     if (!entry->wr_highest_offset_valid) {
-        if (virStorageSourceGetActualType(disk->src) == VIR_STORAGE_TYPE_BLOCK &&
-            disk->src->format != VIR_STORAGE_FILE_RAW) {
-            virReportError(VIR_ERR_INTERNAL_ERROR,
-                           _("failed to query the maximum written offset of "
-                             "block device '%s'"), disk->dst);
-            goto endjob;
-        }
-
         info->allocation = entry->physical;
     } else {
         if (virStorageSourceGetActualType(disk->src) == VIR_STORAGE_TYPE_FILE &&
-- 
2.12.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 05/29/2017 11:04 AM, Peter Krempa wrote:
> qemuDomainGetBlockInfo would error out if qemu did not report
> 'wr_highest_offset'. This usually does not happen, but can happen
> briefly during active layer block commit. There's no need to report the
> error, we can simply report that the disk is fully alocated at that

s/alocated/allocated

> point.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1452045
> ---
>  src/qemu/qemu_driver.c | 8 --------
>  1 file changed, 8 deletions(-)
> 

I am curious why this isn't a QEMU bug?

Secondarily given what I read in the bz, if the qemuDomainGetBlockInfo
thread does continue it will display the physical (which is fine), but
once the qemu command can succeed again and wr_highest_offset is valid
again - will it be less than the physical now?  IOW: Is there a "period"
that an incorrect value would be displayed because of the failure to
return the value and could that be misconstrued some how?  Should that
be documented in the block commit API description?

Side thought - do we perhaps want to add a VIR_DEBUG msg about the
missing data?

Reviewed-by: John Ferlan <jferlan@redhat.com>

John

> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 67f54282a..f6b352b56 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -11541,14 +11541,6 @@ qemuDomainGetBlockInfo(virDomainPtr dom,
>      }
> 
>      if (!entry->wr_highest_offset_valid) {
> -        if (virStorageSourceGetActualType(disk->src) == VIR_STORAGE_TYPE_BLOCK &&
> -            disk->src->format != VIR_STORAGE_FILE_RAW) {
> -            virReportError(VIR_ERR_INTERNAL_ERROR,
> -                           _("failed to query the maximum written offset of "
> -                             "block device '%s'"), disk->dst);
> -            goto endjob;
> -        }
> -
>          info->allocation = entry->physical;
>      } else {
>          if (virStorageSourceGetActualType(disk->src) == VIR_STORAGE_TYPE_FILE &&
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list