On Mon, Aug 20, 2018 at 04:07:28PM +0100, Daniel P. Berrangé wrote: > On Tue, Aug 14, 2018 at 01:19:42PM +0200, Michal Privoznik wrote: > > In order for our drivers to lock resources for metadata change we > > need set of new APIs. Fortunately, we don't have to care about > > every possible device a domain can have. We care only about those > > which can live on a network filesystem and hence can be accessed > > by multiple daemons at the same time. These devices are covered > > in virDomainLockMetadataLock() and only a small fraction of > > those can be hotplugged (covered in the rest of the introduced > > APIs). > > I'm not sure I understand the rationale behind saying we only care > about resources on network filesystems. > > If I have 2 locally running guests, and both have a serial port > backed by a physical serial port, eg > > <serial type="dev"> > <source path="/dev/ttyS0"/> > <target port="1"/> > </serial> > > we *do* care about locking /dev/ttyS0, as libvirtd isn't doing > mutual exclusion checks anywhere else for the /dev/ttyS0 device > node. > > In general I think we need to lock every single file resource > that is labelled for a guest, regardless of whether its local > or remote. In the next patch I propose integration into the security manager that would avoid the need to touch this domain lock abstraction at all. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list