Le 21/09/2017 à 16:31, Stefan Hajnoczi a écrit :
On Tue, Sep 19, 2017 at 12:09:06PM +0200, Nicolas Ecarnot wrote:
Hello,
First post here, so maybe I should introduce myself :
- I'm a sysadmin for decades and currently managing 4 oVirt clusters, made
out of tens of hypervisors, all are CentOS 7.2+ based.
- I'm very happy with this solution we choose especially because it is based
on qemu-kvm (open source, reliable, documented).
On one VM, we experienced the following :
- oVirt/vdsm is detecting an issue on the image
- following this hints https://access.redhat.com/solutions/1173623, I
managed to detect one error and fix it
- the VM is now running perfectly
On two other VMs, we experienced a similar situation, except the check stage
is showing something like 14000+ errors, and the relevant logs are :
Repairing refcount block 14 is outside image
ERROR could not resize image: Invalid argument
ERROR cluster 425984 refcount=0 reference=1
ERROR cluster 425985 refcount=0 reference=1
[... repeating the previous line 7000+ times...]
ERROR cluster 457166 refcount=0 reference=1
Rebuilding refcount structure
ERROR writing refblock: No space left on device
qemu-img: Check failed: No space left on device
Please run strace qemu-img info /the/relevant/logical/volume/path. It
will print all the syscalls that qemu-img makes. That way we'll be able
to verify that the ENOSPC error is coming from a pwritev syscall.
I did but I'm not skilled enough to ensure where the ENOSPC error is
coming from.
Is your question meaning the reads and/or the writes may come from or go
to places outside the expected boundaries?
You surely know that oVirt/RHEV is storing its qcow2 images in dedicated
logical volumes.
pvs/vgs/lvs are all showing there is plenty of space available, so I
understand that I don't understand what "No space left on device" means.
After you have the strace data you can look at the file offset from the
failing pwritev syscall and check that it's really within the LV.
I think there is no fancy thin provisioning going on at the LVM level
with oVirt, but if there is then perhaps a write within the LV could
still result in an ENOSPC error. It would be worth confirming that
these are class "thick" LVs.
I think there is no such thin prov. at the LVM level, but I wouldn't swear.
Don't you mind if I forward your question to the oVirt mailing-list?
--
Nicolas ECARNOT