On Fri, Jul 21, 2017 at 2:36 PM, Eric Blake <ebl...@redhat.com> wrote:
> On 07/21/2017 05:20 AM, Fam Zheng wrote: > > It is reported that on Windows Subsystem for Linux, ofd operations fail > > with -EINVAL. In other words, QEMU binary built with system headers that > > exports F_OFD_SETLK doesn't necessarily run in an environment that > > actually supports it: > > > > $ qemu-system-aarch64 ... -drive file=test.vhdx,if=none,id=hd0 \ > > -device virtio-blk-pci,drive=hd0 > > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to > unlock byte 100 > > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to > unlock byte 100 > > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to > lock byte 100 > > > > Let's do a runtime check to cope with that. > > You may want to mention that the same is possible on a system with old > kernel but new glibc (ie. this issue is not necessarily specific to WSL). > I first thought that this combination hitting me as I run KVM in containers which can diverge glibc (in container) a lot from kernel (in host). My issue turned out to be an apparmor block instead. But since I clearly see how my case could lead to the mentioned old kernel but new glibc I wanted to ping here to refresh/reconsider this change as well. Also the reply might be worth as documentation if people search for the error message and get here that the following apparmor block leads to the same. apparmor="DENIED" operation="file_lock" namespace="root//lxd-testkvm-artful-from_<var-lib-lxd>" profile="libvirt-f687a9b3-5bca-41bc-b206-6e616720cc5e" name="/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow" pid=7001 comm="qemu-system-x86" requested_mask="k" denied_mask="k" fsuid=0 ouid=0 I'll work on libvirt's virt-aa-helper to generate a rule appropriate for the new behavior.
