On Thu, Oct 27, 2016 at 4:09 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list