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 :|