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@xxxxxxxxxx> 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
