On 08/20/2018 05:07 PM, 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.
Ah you mean that the system wide daemon and session daemon could clash when relabeling /dev/ttyS0? Well, we don't do relabeling for session daemons and running two system daemons is not supported (you're gonna hit more serious problems when trying that anyway).
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.
Well this might be feasible iff locking would be done from security driver. Michal