Am 17.02.2020 um 16:16 hat Nir Soffer geschrieben:
On Mon, Feb 17, 2020, 16:53 <jeremy_tourville(a)hotmail.com>
wrote:
> I have seen this error message repeatedly when reviewing events.
>
> VDSM vmh.cyber-range.lan command HSMGetAllTasksStatusesVDS failed: low
> level Image copy failed: ("Command ['/usr/bin/qemu-img',
'convert', '-p',
> '-t', 'none', '-T', 'none', '-f',
'raw',
>
u'/rhev/data-center/mnt/glusterSD/storage.cyber-range.lan:_vmstore/dd69364b-2c02-4165-bc4b-2f2a3b7fc10d/images/c651575f-75a0-492e-959e-8cfee6b6a7b5/9b5601fe-9627-4a8a-8a98-4959f68fb137',
> '-O', 'qcow2', '-o', 'compat=1.1',
>
u'/rhev/data-center/mnt/glusterSD/storage.cyber-range.lan:_vmstore/dd69364b-2c02-4165-bc4b-2f2a3b7fc10d/images/6a2ce11a-deec-41e0-a726-9de6ba6d4ddd/6d738c08-0f8c-4a10-95cd-eeaa2d638db5']
> failed with rc=1 out='' err=bytearray(b'qemu-img: error while reading
> sector 24117243: No such file or directory\\n')",)
>
Looks like copying image failed with ENOENT while reading
offset 12348028416 (11.49 GiB).
I never seen such failure, typically after opening a file read will never
fail with such error, but in gluster this may be possible.
Please share vdsm log showingn this error, it may add useful info.
Also glusterfs client logs from
/var/log/glusterfs*/*storage.cyber-range.lan*.log
Kevin, Krutika, do you have an idea about this error?
This is a weird one. Not only that reading shouldn't be looking up any
filename, but also that it's not at offset 0, but suddenly somewhere in
the middle of the image file.
I think it's pretty safe to say that this error doesn't come from QEMU,
but from the kernel. Did you (or some software) change anything about
the volume in the background while the convert operation was running?
Kevin