[libvirt] [PATCH 11/17] util: Introduce libvirt_udevhelper

[Michal Sekletar]

On Thu, Oct 27, 2016 at 4:09 PM, Daniel P. Berrange <berrange at 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