Re: [libvirt-users] stream finish throws exception via python API
Hi,
sorry to dig up the old thread, but I've recently discovered that it is
possible to get the physical size via virDomainGetBlockInfo(). I am
bringing this up because the call works also on files and not only on
block devices (as the name does suggest).
So, is there any reason why not to use this as a workaround for now?
Is this behaviour of virDomainGetBlockInfo() intended or a bug?
Thanks,
Tomas
On Wed, 27 Apr 2016 10:37:08 -0400
Cole Robinson <crobinso(a)redhat.com> wrote:
On 04/27/2016 04:26 AM, Daniel P. Berrange wrote:
> On Tue, Apr 26, 2016 at 03:17:19PM -0400, Cole Robinson wrote:
>> On 04/26/2016 02:56 PM, Nir Soffer wrote:
>>> On Tue, Apr 26, 2016 at 4:37 PM, Cole Robinson <crobinso(a)redhat.com>
wrote:
>>>> On 04/26/2016 09:35 AM, Shahar Havivi wrote:
>>>>> On 26.04.16 15:30, Shahar Havivi wrote:
>>>>
>>>> Libvirt doesn't invoke qemu-img check anywhere AFAIK, so if
that's the only
>>>> way to get that info, then it isn't available
>>>
>>> We would like to report progress for downloads, so we need to know in
advance
>>> what is the size of the download.
>>>
>>> I guess we can use an estimate (e.g. capacity * 1.1), or maybe someone have
>>> a better idea how to estimate the download size?
>>>
>>
>> Hmm, I didn't realize <capacity> for a qcow2 volume isn't the full
size on
>> disk, but instead the size of the virtual disk image. We should probably add
>> an extra volume field to report the actual on disk size too. Please file a
>> RHEL bug
>
> <physical> is intended to give the actual size on disk.
>
Hmm I see we do track a src->physical value via virstoragefile but that isn't
reflected in the storage volume XML at all, there's no <physical> XML element.
Should be simple to add, but someone on ovirt side please file an RFE so it's
properly prioritized
Thanks,
Cole
--
Tomáš Golembiovský <tgolembi(a)redhat.com>