Re: [libvirt] [PATCH 11/17] util: Introduce libvirt_udevhelper
On Thu, Oct 27, 2016 at 4:09 PM, Daniel P. Berrange <berrange(a)redhat.com> wrote:
We should never be spawning a VM using a disk at the same time as
the
underlying device is appearing - other unrelated devices may be
appearing/disappearing at this time, but not the one the VM is using.
The only reason we're hitting this problem with udev is not because
the storage is changing, it is because some other process (eg a
background monitoring app) has closed the device triggerring the
udev to arbitrarily change the devices.
udev by default watches some device nodes with inotify because there
is no generic kernel interface, i.e. ioctl() that block device
management tools can call once they finish their job. For example, if
a filesystem is initialized we need to pull in some fs related
information to udev database (e.g. fs label). But AFAIK there is no
block layer ioctl that mkfs could call and tell kernel to generate
change event for the device. Hence udev watches devices and
synthesizes change event from user-space.
If we can just stop udev resetting device permissions on FD close
we would not have to deal with any of this problem.
> Is libvirt really not waiting for udev at all?
We only wait for udev in cases where we are dealing with storage
setup. eg when we login to an iSCSI target, or when we activate a
LVM volume group, etc. None of these things are in the VM startup
code path.
Ok, so possible race I am trying to address is non-existent in
practice. In that case I will not do that.
Thanks,
Michal