[libvirt-users] stream finish throws exception via python API
Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error: stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish() libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally Am I doing something wrong? Thank you, Shahar.
On 17.04.16 15:41, Shahar Havivi wrote:
Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error:
stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish()
libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally
Ping...
Am I doing something wrong?
Thank you, Shahar.
On 04/25/2016 08:10 AM, Shahar Havivi wrote:
On 17.04.16 15:41, Shahar Havivi wrote:
Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error:
stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish()
libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally
The error message sucks, I'll send patches to improve it a little at least. What's happening here is that the you haven't read all the data you requested (it's vol.download(path, offset, length, flags), length == 0 means read the whole file which I suspect you haven't done). In this case the iohelper program that libvirt uses won't complete feeding us all the data, and it exits with SIGPIPE when we close the read end of the pipe. Now whether that should actually be an error condition is open to debate. virStreamFinish docs make it sound like it's legitimate to throw an error if it appears that all requested data wasn't read. /** * virStreamFinish: * @stream: pointer to the stream object * * Indicate that there is no further data to be transmitted * on the stream. For output streams this should be called once * all data has been written. For input streams this should be * called once virStreamRecv returns end-of-file. * * This method is a synchronization point for all asynchronous * errors, so if this returns a success code the application can * be sure that all data has been successfully processed. * * Returns 0 on success, -1 upon error */ So maybe in your case you want virStreamAbort instead (which also unconditionally throws an error which is also an issue IMO but can be ignored) CCing danpb for this thoughts on the erroring semantics - Cole
On 25.04.16 09:11, Cole Robinson wrote:
On 04/25/2016 08:10 AM, Shahar Havivi wrote:
On 17.04.16 15:41, Shahar Havivi wrote:
Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error:
stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish()
libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally
The error message sucks, I'll send patches to improve it a little at least.
What's happening here is that the you haven't read all the data you requested (it's vol.download(path, offset, length, flags), length == 0 means read the whole file which I suspect you haven't done). In this case the iohelper program that libvirt uses won't complete feeding us all the data, and it exits with SIGPIPE when we close the read end of the pipe.
Now whether that should actually be an error condition is open to debate. virStreamFinish docs make it sound like it's legitimate to throw an error if it appears that all requested data wasn't read. Thanks checking...
/** * virStreamFinish: * @stream: pointer to the stream object * * Indicate that there is no further data to be transmitted * on the stream. For output streams this should be called once * all data has been written. For input streams this should be * called once virStreamRecv returns end-of-file. * * This method is a synchronization point for all asynchronous * errors, so if this returns a success code the application can * be sure that all data has been successfully processed. * * Returns 0 on success, -1 upon error */
So maybe in your case you want virStreamAbort instead (which also unconditionally throws an error which is also an issue IMO but can be ignored)
CCing danpb for this thoughts on the erroring semantics
- Cole
On 26.04.16 14:14, Shahar Havivi wrote:
On 25.04.16 09:11, Cole Robinson wrote:
On 04/25/2016 08:10 AM, Shahar Havivi wrote:
On 17.04.16 15:41, Shahar Havivi wrote:
Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error:
stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish()
libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally
The error message sucks, I'll send patches to improve it a little at least.
What's happening here is that the you haven't read all the data you requested (it's vol.download(path, offset, length, flags), length == 0 means read the whole file which I suspect you haven't done). In this case the iohelper program that libvirt uses won't complete feeding us all the data, and it exits with SIGPIPE when we close the read end of the pipe.
Now whether that should actually be an error condition is open to debate. virStreamFinish docs make it sound like it's legitimate to throw an error if it appears that all requested data wasn't read. Thanks checking... Thanks Cole, I modify our script and for checking if stream.recv() returns zero the finish works fine. Our API needs to know the size of bytes that you are going to stream back which is not provided by the allocation and capacity. (ie the same as du -s /path/to/disk)
Shahar.
/** * virStreamFinish: * @stream: pointer to the stream object * * Indicate that there is no further data to be transmitted * on the stream. For output streams this should be called once * all data has been written. For input streams this should be * called once virStreamRecv returns end-of-file. * * This method is a synchronization point for all asynchronous * errors, so if this returns a success code the application can * be sure that all data has been successfully processed. * * Returns 0 on success, -1 upon error */
So maybe in your case you want virStreamAbort instead (which also unconditionally throws an error which is also an issue IMO but can be ignored)
CCing danpb for this thoughts on the erroring semantics
- Cole
On 26.04.16 15:30, Shahar Havivi wrote:
On 26.04.16 14:14, Shahar Havivi wrote:
On 25.04.16 09:11, Cole Robinson wrote:
On 04/25/2016 08:10 AM, Shahar Havivi wrote:
On 17.04.16 15:41, Shahar Havivi wrote:
Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error:
stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish()
libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally
The error message sucks, I'll send patches to improve it a little at least.
What's happening here is that the you haven't read all the data you requested (it's vol.download(path, offset, length, flags), length == 0 means read the whole file which I suspect you haven't done). In this case the iohelper program that libvirt uses won't complete feeding us all the data, and it exits with SIGPIPE when we close the read end of the pipe.
Now whether that should actually be an error condition is open to debate. virStreamFinish docs make it sound like it's legitimate to throw an error if it appears that all requested data wasn't read. Thanks checking... Thanks Cole, I modify our script and for checking if stream.recv() returns zero the finish works fine. Our API needs to know the size of bytes that you are going to stream back which is not provided by the allocation and capacity. (ie the same as du -s /path/to/disk)
Shahar. We need the size of the image "Image end offset" you get from "qemu-img check", Does libvirt have an API for that?
Thanks, Shahar.
/** * virStreamFinish: * @stream: pointer to the stream object * * Indicate that there is no further data to be transmitted * on the stream. For output streams this should be called once * all data has been written. For input streams this should be * called once virStreamRecv returns end-of-file. * * This method is a synchronization point for all asynchronous * errors, so if this returns a success code the application can * be sure that all data has been successfully processed. * * Returns 0 on success, -1 upon error */
So maybe in your case you want virStreamAbort instead (which also unconditionally throws an error which is also an issue IMO but can be ignored)
CCing danpb for this thoughts on the erroring semantics
- Cole
On 04/26/2016 09:35 AM, Shahar Havivi wrote:
On 26.04.16 15:30, Shahar Havivi wrote:
On 26.04.16 14:14, Shahar Havivi wrote:
On 25.04.16 09:11, Cole Robinson wrote:
On 04/25/2016 08:10 AM, Shahar Havivi wrote:
On 17.04.16 15:41, Shahar Havivi wrote:
Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error:
stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish()
libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally
The error message sucks, I'll send patches to improve it a little at least.
What's happening here is that the you haven't read all the data you requested (it's vol.download(path, offset, length, flags), length == 0 means read the whole file which I suspect you haven't done). In this case the iohelper program that libvirt uses won't complete feeding us all the data, and it exits with SIGPIPE when we close the read end of the pipe.
Now whether that should actually be an error condition is open to debate. virStreamFinish docs make it sound like it's legitimate to throw an error if it appears that all requested data wasn't read. Thanks checking... Thanks Cole, I modify our script and for checking if stream.recv() returns zero the finish works fine. Our API needs to know the size of bytes that you are going to stream back which is not provided by the allocation and capacity. (ie the same as du -s /path/to/disk)
Shahar. We need the size of the image "Image end offset" you get from "qemu-img check", Does libvirt have an API for that?
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 - Cole
On Tue, Apr 26, 2016 at 4:37 PM, Cole Robinson <crobinso@redhat.com> wrote:
On 04/26/2016 09:35 AM, Shahar Havivi wrote:
On 26.04.16 15:30, Shahar Havivi wrote:
On 26.04.16 14:14, Shahar Havivi wrote:
On 25.04.16 09:11, Cole Robinson wrote:
On 04/25/2016 08:10 AM, Shahar Havivi wrote:
On 17.04.16 15:41, Shahar Havivi wrote: > Hi, > The following snippet works fine e.g. receiving the data but when calling > stream.finish() we get the following error: > > stream = con.newStream() > vol.download(stream, 0, 0, 0) > buf = stream.recv(1024) > stream.finish() > > libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally > Traceback (most recent call last): > File "./helpers/kvm2ovirt", line 149, in <module> > download_volume(vol, item[1], diskno, disksitems, pksize) > File "./helpers/kvm2ovirt", line 102, in download_volume > stream.finish() > File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish > if ret == -1: raise libvirtError ('virStreamFinish() failed') > libvirt.libvirtError: internal error: I/O helper exited abnormally >
The error message sucks, I'll send patches to improve it a little at least.
What's happening here is that the you haven't read all the data you requested (it's vol.download(path, offset, length, flags), length == 0 means read the whole file which I suspect you haven't done). In this case the iohelper program that libvirt uses won't complete feeding us all the data, and it exits with SIGPIPE when we close the read end of the pipe.
Now whether that should actually be an error condition is open to debate. virStreamFinish docs make it sound like it's legitimate to throw an error if it appears that all requested data wasn't read. Thanks checking... Thanks Cole, I modify our script and for checking if stream.recv() returns zero the finish works fine. Our API needs to know the size of bytes that you are going to stream back which is not provided by the allocation and capacity. (ie the same as du -s /path/to/disk)
Shahar. We need the size of the image "Image end offset" you get from "qemu-img check", Does libvirt have an API for that?
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? A second issue, libvirt does not seem to understand sparseness, so we are copying around gigabytes of zeros. For example, I created 102M empty image (using virt manager): $ qemu-img info /home/nsoffer/var/libvirt/images/tiny.qcow2 image: /home/nsoffer/var/libvirt/images/tiny.qcow2 file format: qcow2 virtual size: 102M (107374592 bytes) disk size: 304K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false Downloading it using the attach test script: $ python download.py /home/nsoffer/var/libvirt/images/tiny.qcow2 written 107741184 bytes $ qemu-img info download.qcow2 image: download.qcow2 file format: qcow2 virtual size: 102M (107374592 bytes) disk size: 103M cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false Same operation using qemu-img convert: $ qemu-img convert -O qcow2 /home/nsoffer/var/libvirt/images/tiny.qcow2 convert.qcow2 $ qemu-img info convert.qcow2 image: convert.qcow2 file format: qcow2 virtual size: 102M (107374592 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false So with libvirt we downloaded 102M, and qemu copied only 196K. Nir
On 04/26/2016 02:56 PM, Nir Soffer wrote:
On Tue, Apr 26, 2016 at 4:37 PM, Cole Robinson <crobinso@redhat.com> wrote:
On 04/26/2016 09:35 AM, Shahar Havivi wrote:
On 26.04.16 15:30, Shahar Havivi wrote:
On 26.04.16 14:14, Shahar Havivi wrote:
On 25.04.16 09:11, Cole Robinson wrote:
On 04/25/2016 08:10 AM, Shahar Havivi wrote: > On 17.04.16 15:41, Shahar Havivi wrote: >> Hi, >> The following snippet works fine e.g. receiving the data but when calling >> stream.finish() we get the following error: >> >> stream = con.newStream() >> vol.download(stream, 0, 0, 0) >> buf = stream.recv(1024) >> stream.finish() >> >> libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally >> Traceback (most recent call last): >> File "./helpers/kvm2ovirt", line 149, in <module> >> download_volume(vol, item[1], diskno, disksitems, pksize) >> File "./helpers/kvm2ovirt", line 102, in download_volume >> stream.finish() >> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish >> if ret == -1: raise libvirtError ('virStreamFinish() failed') >> libvirt.libvirtError: internal error: I/O helper exited abnormally >>
The error message sucks, I'll send patches to improve it a little at least.
What's happening here is that the you haven't read all the data you requested (it's vol.download(path, offset, length, flags), length == 0 means read the whole file which I suspect you haven't done). In this case the iohelper program that libvirt uses won't complete feeding us all the data, and it exits with SIGPIPE when we close the read end of the pipe.
Now whether that should actually be an error condition is open to debate. virStreamFinish docs make it sound like it's legitimate to throw an error if it appears that all requested data wasn't read. Thanks checking... Thanks Cole, I modify our script and for checking if stream.recv() returns zero the finish works fine. Our API needs to know the size of bytes that you are going to stream back which is not provided by the allocation and capacity. (ie the same as du -s /path/to/disk)
Shahar. We need the size of the image "Image end offset" you get from "qemu-img check", Does libvirt have an API for that?
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
A second issue, libvirt does not seem to understand sparseness, so we are copying around gigabytes of zeros.
The sparseness issue is being worked on presently: https://bugzilla.redhat.com/show_bug.cgi?id=1282859 - Cole
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@redhat.com> wrote:
On 04/26/2016 09:35 AM, Shahar Havivi wrote:
On 26.04.16 15:30, Shahar Havivi wrote:
On 26.04.16 14:14, Shahar Havivi wrote:
On 25.04.16 09:11, Cole Robinson wrote: > On 04/25/2016 08:10 AM, Shahar Havivi wrote: >> On 17.04.16 15:41, Shahar Havivi wrote: >>> Hi, >>> The following snippet works fine e.g. receiving the data but when calling >>> stream.finish() we get the following error: >>> >>> stream = con.newStream() >>> vol.download(stream, 0, 0, 0) >>> buf = stream.recv(1024) >>> stream.finish() >>> >>> libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally >>> Traceback (most recent call last): >>> File "./helpers/kvm2ovirt", line 149, in <module> >>> download_volume(vol, item[1], diskno, disksitems, pksize) >>> File "./helpers/kvm2ovirt", line 102, in download_volume >>> stream.finish() >>> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish >>> if ret == -1: raise libvirtError ('virStreamFinish() failed') >>> libvirt.libvirtError: internal error: I/O helper exited abnormally >>> > > The error message sucks, I'll send patches to improve it a little at least. > > What's happening here is that the you haven't read all the data you requested > (it's vol.download(path, offset, length, flags), length == 0 means read the > whole file which I suspect you haven't done). In this case the iohelper > program that libvirt uses won't complete feeding us all the data, and it exits > with SIGPIPE when we close the read end of the pipe. > > Now whether that should actually be an error condition is open to debate. > virStreamFinish docs make it sound like it's legitimate to throw an error if > it appears that all requested data wasn't read. Thanks checking... Thanks Cole, I modify our script and for checking if stream.recv() returns zero the finish works fine. Our API needs to know the size of bytes that you are going to stream back which is not provided by the allocation and capacity. (ie the same as du -s /path/to/disk)
Shahar. We need the size of the image "Image end offset" you get from "qemu-img check", Does libvirt have an API for that?
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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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@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
בתאריך 27 באפר׳ 2016 5:37 אחה״צ, "Cole Robinson" <crobinso@redhat.com> כתב:
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@redhat.com>
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
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
wrote: the only 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
Sure, we will file a bug.
Thanks, Cole
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@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@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@redhat.com>
participants (5)
-
Cole Robinson -
Daniel P. Berrange -
Nir Soffer -
Shahar Havivi -
Tomáš Golembiovský