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

[Daniel P. Berrange]

On Thu, Oct 27, 2016 at 04:02:33PM +0200, Michal Sekletar wrote:
> On Thu, Oct 27, 2016 at 3:45 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> > We can not do any sychronous wait against udev doing work - that will
> > add an unacceptable delay in the VM startup process - it is already
> > too long and we don't want to design a system that will make it even
> > slower.
> 
> Note that if implemented it would be very targeted wait for one
> specific event. It *won't* be an equivalent of udevadm settle. In
> "uncontented" case udev's response should be very quick. Otherwise,
> something (e.g. lv resize) is still setting up a block device because
> change events are still being processed for it, and if that is the
> case, then just spawning qemu and hoping for the best doesn't seem
> right to me (disregarding SELinux and permission issues).

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.

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|