I don't recall running any convert operations on the host and certainly not on the time/date listed. *If* I ran any conversions were run, they were run from a laptop and then I moved the converted disk to this host. I definitely didn't make any volume changes. Is this image conversion part of the template process? I have been creating quite a few templates lately. I have noted that several of them failed and I had to rerun the process. Is this some sort of process that just keeps trying over and over because it thinks it failed? That's the only theory I can come up with.

From: Kevin Wolf <kwolf@redhat.com>
Sent: Tuesday, February 18, 2020 3:01 AM
To: Nir Soffer <nsoffer@redhat.com>
Cc: jeremy_tourville@hotmail.com <jeremy_tourville@hotmail.com>; users <users@ovirt.org>; Krutika Dhananjay <kdhananj@redhat.com>
Subject: Re: [ovirt-users] What is this error message from?

Am 17.02.2020 um 16:16 hat Nir Soffer geschrieben:
> On Mon, Feb 17, 2020, 16:53 <jeremy_tourville@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