On Thu, Jun 20, 2019 at 02:32:40PM +0200, Michal Privoznik wrote: > On 6/20/19 1:58 PM, Daniel P. Berrangé wrote: > > On Thu, Jun 20, 2019 at 12:23:07PM +0200, Michal Privoznik wrote: > > > On 6/17/19 3:29 PM, Daniel P. Berrangé wrote: > > > > On Thu, Apr 25, 2019 at 10:19:54AM +0200, Michal Privoznik wrote: > > > > > This effectively reverts d7420430ce6 and adds new code. > > > > > > > > > > Here is the problem: Imagine a file X that is to be shared > > > > > between two domains as a disk. Let the first domain (vm1) have > > > > > seclabel remembering turned on and the other (vm2) has it turned > > > > > off. Assume that both domains will run under the same user, but > > > > > the original owner of X is different (i.e. trying to access X > > > > > without relabelling leads to EPERM). > > > > > > > > How do we get into this situation ? Is this the case when we > > > > have a guest which was running before libvirt was upgraded, and > > > > then a new guest is launched ? > > > > > > Yes, that's one of the possible scenarios. Another possible scenario would > > > be (and this won't happen yet in reality beacuse NFS still does not > > > implement XATTRs, but once they do we might hit it): two daemons and one > > > shared NFS mount. One of the daemons has the feature enabled, the other has > > > it disabled. But as I say, this won't happen with NFS today. But maybe there > > > are some other shared filesystems which do implement XATTRs? > > > > IMHO if you are using a set of virt hosts with a shared NFS and have only > > enabled label mgmt on a subset of hosts that's a deployment error in > > general. > > > > Having said that, this is precisely the scearnio you'd have if you are > > part way through a libvirt upgrade across many hosts. > > > > Our core problem is that we have zero knowledge about other hosts, neither > > their config, or even whether they exist at all, so we can't do the safe > > thing automatically. > > Yep, this is the root cause of the problem. > > > > > I'm still not a fan of just giving up & deleting the feature though. > > > > How about we create a qemu.conf option to turn on/off label mgmt for > > shared volumes, defaulting to off. Document that it should only be > > turned off if all hosts are participating & no historical VMs are > > running ? > > This could work. But if possible, I'd probably do that in a follow up > series? I mean, this series is long enough already and I can see it > working/being merged as I write what you suggest. Yep, no objection to that. > > In theory on upgrade, we could look at all running VMs on our own host > > and record the ref count data that is otherwise missing. That could at > > least let it work correctly on a the single-host non-shared FS scenario. > > Yeah, since we don't know about other daemons we could do that only for > local files. 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
