On 7/18/19 8:46 AM, Michal Privoznik wrote:
On 7/17/19 7:20 PM, Daniel Henrique Barboza wrote:
After this commit, QEMU domains with PCI hostdevs running with
managed=true started to fail to launch with the following error:
error : virProcessRunInFork:1170 : internal error: child reported
(status=125): unable to open /dev/vfio/1: Device or resource busy
One way to avoid this issue is to disable this new feature
in qemu.conf, setting remember_owner=0. However, given that
this feature is enabled by default and it is breaking domains that
were running before it, it is best to revert the change until
it is fixed for this scenario as well.
Well, ideally, we want the feature to be turned on by default, just like
namespaces for instance. I've temporarily disabled the feature back in
the day because we were close to release and it turned out the feature
was not ready. But now there is still plenty of time to fix it.
Anyway, I'll investigate. Meanwhile, can you share your <hostdev/>
config or even better the full domain definition please?
Okay, so I think I know what is going on. You have two <hostdev/>-s in
your domain and both of them belong to the same IOMMU group, right?
If that is the case, then the same path appears twice in the list of
paths passed to virSecurityManagerMetadataLock(). For instance, in my case:
Thread 2.1 "libvirtd" hit Breakpoint 3, virSecurityManagerMetadataLock
(mgr=0x7f365c026660, paths=0x7f36a001c1e0, npaths=6) at
security/security_manager.c:1283
1283 {
virSecurityManagerMetadataLock 1 # p *paths@npaths
$6 = {0x7f36a0027720 "/var/lib/libvirt/images/fedora.qcow2",
0x7f36a001a660 "/var/lib/libvirt/images/fd.img",
0x7f36a001c470
"/dev/disk/by-path/ip-10.37.132.232:3260-iscsi-iqn.2017-03.com.mprivozn:server-lun-1",
0x7f36a00262b0 "/dev/vfio/9",
0x7f36a0025e20 "/dev/vfio/9",
0x7f36a001d880
"/var/lib/libvirt/qemu/channel/target/domain-1-fedora/org.qemu.guest_agent.0"}
The "/dev/vfio/9" path is there twice because I have this graphics card
that has two functions and I'm passing them both into the domain. The
problem here is that when virSecurityManagerMetadataLock() gets to first
/dev/vfio/9 path, it opens it and locks it. Then it wants to process the
next path (which is the same path), but it fails open()-ing the path,
because it's locked. Honestly, I don't know if that is expected
behaviour, but even it if wasn't then we would fail to lock the path
second time. I'm proposing a fix in no time.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
