6:26 p.m.
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
6:42 p.m.
On Wed, Nov 21, 2018 at 4:26 PM Gianluca Cecchi <gianluca.cecchi(a)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
10:54 p.m.
On Wed, Nov 21, 2018, 17:28 Gianluca Cecchi <gianluca.cecchi(a)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...
Nir
12:44 a.m.
Use -c during conversion for compressing.
Regards,
Sinan
Op 21 nov. 2018 om 20:54 heeft Nir Soffer <nsoffer(a)redhat.com>
het volgende geschreven:
> On Wed, Nov 21, 2018, 17:28 Gianluca Cecchi <gianluca.cecchi(a)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...
Nir
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/5TDJTW4XQEA...
12:47 p.m.
Thanks both for your answers.
On Wed, Nov 21, 2018 at 10:44 PM Sinan Polat <sinan(a)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(a)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...
>
You hit
https://bugzilla.redhat.com/1627032
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
10 p.m.
On Thu, Nov 22, 2018, 11:47 Gianluca Cecchi <gianluca.cecchi(a)gmail.com
wrote:
Thanks both for your answers.
On Wed, Nov 21, 2018 at 10:44 PM Sinan Polat <sinan(a)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(a)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...
>>
>
> You hit
> https://bugzilla.redhat.com/1627032
>
>
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
2192
days inactive
2193
days old
5 comments
3 participants
participants (3)
-
Gianluca Cecchi -
Nir Soffer -
Sinan Polat