Best way to add qcow2 file to block storage domain
Hello, I have a qcow2 image file with these details with "qemu-img info" command: file format: qcow2 virtual size: 66G (70866960384 bytes) disk size: 1.5G cluster_size: 65536 Format specific information: compat: 0.10 I'm on 4.2.6 and If I try to upload as a disk from the GUI it seems it tries to upload full 66Gb, not 1.5Gb... And it goes paused after the probably transferred 1.5Gb... Also, I would like it to be qcow2 1.1 and not 0.10 I have run: qemu-img convert -O qcow2 -o compat=1.1 source.qc2 source.qc2_v3 and now I have file format: qcow2 virtual size: 66G (70866960384 bytes) disk size: 4.2G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false Is it expected to pass from 1.5Gb to 4.2Gb after conversion? Anyway also in 1.1 format, if I try to upload It keeps sending the whole 66Gb and now it goes in paused after about 1 minute (at rate of 60MB/s) that lets me think that once arrived at the 4.2Gb size it has problems... Any hint? Thanks, Gianluca
On Wed, Nov 21, 2018 at 4:26 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote: [snip]
Anyway also in 1.1 format, if I try to upload It keeps sending the whole 66Gb and now it goes in paused after about 1 minute (at rate of 60MB/s) that lets me think that once arrived at the 4.2Gb size it has problems...
Any hint?
Thanks, Gianluca
In image-proxy.log of engine (Thread-83 ) ERROR 2018-11-21 16:22:40,402 web:136:web:(log_error) ERROR [10.4.23.16] PUT /images/8e9b2b60-4d5a-4dd8-bd49-8f85ebc6349e [500] Failed response from host: 500 {"explanation": "The server has either erred or is incapable of performing the requested operation.", "code": 500, "detail": "[Errno 22] Invalid argument", "title": "Internal Server Error"} [request=0.006663] Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/web.py", line 99, in __call__ resp = self.dispatch(request, clock) File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/web.py", line 128, in dispatch return method(*match.groups()) File "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/http_helper.py", line 86, in wrapper return func(self, *args) File "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/http_helper.py", line 59, in wrapper ret = func(self, *args) File "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/images.py", line 153, in put read_timeout=self.config.imaged_read_timeout_sec) File "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/images.py", line 239, in make_imaged_request raise exc.status_map[imaged_resp.status_code](s) HTTPInternalServerError: Failed response from host: 500 {"explanation": "The server has either erred or is incapable of performing the requested operation.", "code": 500, "detail": "[Errno 22] Invalid argument", "title": "Internal Server Error"} Inside daemon.log of host involved I have several lines of this type during the transfer 2018-11-21 16:22:40,359 INFO (Thread-93) [images] [10.4.192.79] WRITE size=0 offset=4928307200 flush=True ticket=8e9b2b60-4d5a-4dd8-bd49-8f85ebc6349e 2018-11-21 16:22:40,379 INFO (Thread-94) [images] [10.4.192.79] WRITE size=0 offset=5033164800 flush=True ticket=8e9b2b60-4d5a-4dd8-bd49-8f85ebc6349e 2018-11-21 16:22:40,400 INFO (Thread-95) [images] [10.4.192.79] WRITE size=0 offset=5138022400 flush=True ticket=8e9b2b60-4d5a-4dd8-bd49-8f85ebc6349e and then: 2018-11-21 16:22:40,400 ERROR (Thread-95) [web] ERROR [10.4.192.79] PUT /images/8e9b2b60-4d5a-4dd8-bd49-8f85ebc6349e [500] [Errno 22] Invalid argument [request=0.000435, operation=0.000109, sync=0.0 00007] Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/web.py", line 99, in __call__ resp = self.dispatch(request, clock) File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/web.py", line 128, in dispatch return method(*match.groups()) File "/usr/lib/python2.7/site-packages/ovirt_imageio_daemon/server.py", line 258, in put ticket.run(op) File "/usr/lib/python2.7/site-packages/ovirt_imageio_daemon/tickets.py", line 107, in run operation.run() File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/directio.py", line 81, in run self._run() File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/directio.py", line 176, in _run remaining = self._seek_before_first_block(dst) File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/directio.py", line 195, in _seek_before_first_block dst.seek(self._offset) File "/usr/lib64/python2.7/site-packages/ovirt_imageio_common/directio.py", line 445, in seek return self._fio.seek(pos, how) IOError: [Errno 22] Invalid argument 2018-11-21 16:22:43,435 INFO (Thread-96) [images] [10.4.192.79] OPTIONS ticket=8e9b2b60-4d5a-4dd8-bd49-8f85ebc6349e 2018-11-21 16:22:43,452 INFO (Thread-97) [images] [10.4.192.79] WRITE size=0 offset=5138022400 flush=True ticket=8e9b2b60-4d5a-4dd8-bd49-8f85ebc6349e
On Wed, Nov 21, 2018, 17:28 Gianluca Cecchi <gianluca.cecchi@gmail.com wrote:
Hello, I have a qcow2 image file with these details with "qemu-img info" command:
file format: qcow2 virtual size: 66G (70866960384 bytes) disk size: 1.5G cluster_size: 65536 Format specific information: compat: 0.10
I'm on 4.2.6 and If I try to upload as a disk from the GUI it seems it tries to upload full 66Gb, not 1.5Gb...
You hit https://bugzilla.redhat.com/1627032 And it goes paused after the probably transferred 1.5Gb...
Also, I would like it to be qcow2 1.1 and not 0.10 I have run:
qemu-img convert -O qcow2 -o compat=1.1 source.qc2 source.qc2_v3
This works, but you can use amend instead of convert. You can also upload the image as is, oVirt amend the image to use 1.1 after the upload.
and now I have file format: qcow2 virtual size: 66G (70866960384 bytes) disk size: 4.2G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
Is it expected to pass from 1.5Gb to 4.2Gb after conversion?
The original image probaly had some compressed clusters. Converting uncompress all clusters.
Anyway also in 1.1 format, if I try to upload It keeps sending the whole 66Gb and now it goes in paused after about 1 minute (at rate of 60MB/s) that lets me think that once arrived at the 4.2Gb size it has problems...
Same issue
Any hint?
Update to 4.2.7, or upload using the SDK: https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_di... Nir
Use -c during conversion for compressing. Regards, Sinan
Op 21 nov. 2018 om 20:54 heeft Nir Soffer <nsoffer@redhat.com> het volgende geschreven:
On Wed, Nov 21, 2018, 17:28 Gianluca Cecchi <gianluca.cecchi@gmail.com wrote: Hello, I have a qcow2 image file with these details with "qemu-img info" command:
file format: qcow2 virtual size: 66G (70866960384 bytes) disk size: 1.5G cluster_size: 65536 Format specific information: compat: 0.10
I'm on 4.2.6 and If I try to upload as a disk from the GUI it seems it tries to upload full 66Gb, not 1.5Gb...
You hit https://bugzilla.redhat.com/1627032
And it goes paused after the probably transferred 1.5Gb... Also, I would like it to be qcow2 1.1 and not 0.10 I have run:
qemu-img convert -O qcow2 -o compat=1.1 source.qc2 source.qc2_v3
This works, but you can use amend instead of convert.
You can also upload the image as is, oVirt amend the image to use 1.1 after the upload.
and now I have file format: qcow2 virtual size: 66G (70866960384 bytes) disk size: 4.2G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
Is it expected to pass from 1.5Gb to 4.2Gb after conversion?
The original image probaly had some compressed clusters. Converting uncompress all clusters.
Anyway also in 1.1 format, if I try to upload It keeps sending the whole 66Gb and now it goes in paused after about 1 minute (at rate of 60MB/s) that lets me think that once arrived at the 4.2Gb size it has problems...
Same issue
Any hint?
Update to 4.2.7, or upload using the SDK: https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_di...
Nir _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/5TDJTW4XQEA7FR...
Thanks both for your answers. On Wed, Nov 21, 2018 at 10:44 PM Sinan Polat <sinan@turka.nl> wrote:
Use -c during conversion for compressing.
Regards, Sinan
I confirm that using "-c" option the size of the converted image is the same as the 0.10 version. Thanks. I didn't find a way to verify in advance if an image is compressed or not.. is there?
Op 21 nov. 2018 om 20:54 heeft Nir Soffer <nsoffer@redhat.com> het volgende geschreven:
[snip]
I'm on 4.2.6 and If I try to upload as a disk from the GUI it seems it
tries to upload full 66Gb, not 1.5Gb...
I confirm that after updating the engine (not yet the hosts) from 4.2.6.4 to 4.2.7.5 fixes the problem, both for the displayed disk size inside the gui bar during upload (1.5Gb and not 66Gb) and for the successful completion. Gianluca
On Thu, Nov 22, 2018, 11:47 Gianluca Cecchi <gianluca.cecchi@gmail.com wrote:
Thanks both for your answers.
On Wed, Nov 21, 2018 at 10:44 PM Sinan Polat <sinan@turka.nl> wrote:
Use -c during conversion for compressing.
Regards, Sinan
I confirm that using "-c" option the size of the converted image is the same as the 0.10 version. Thanks. I didn't find a way to verify in advance if an image is compressed or not.. is there?
No. Qcow2 file is not actualy compressed, it includes compressed clusters. This can be detected by looking at qcow2 metadata, but it is not exposed by qemu-img. Nir
Op 21 nov. 2018 om 20:54 heeft Nir Soffer <nsoffer@redhat.com> het volgende geschreven:
[snip]
I'm on 4.2.6 and If I try to upload as a disk from the GUI it seems it
tries to upload full 66Gb, not 1.5Gb...
I confirm that after updating the engine (not yet the hosts) from 4.2.6.4 to 4.2.7.5 fixes the problem, both for the displayed disk size inside the gui bar during upload (1.5Gb and not 66Gb) and for the successful completion.
Yes, this is engine bug so upgrading engine is enough. But you should update the hosts to get other fixes and improvements like https://bugzilla.redhat.com/1511891 Nir
participants (3)
-
Gianluca Cecchi -
Nir Soffer -
Sinan Polat