I've been experiencing dangerous issue that my backing files located on shared storage in _base folder are being removed by nova-compute. It's being happen on Juno, Kilo and Liberty releases. The shared storage mount /var/lib/nova/instances are configured on NFSv3. Backing image ids exists in /var/lib/nova/instances/locks/ folder for affected files. I don't know for sure, how the mechanism preventing _base files from deletion works - if it depends on locks folder or if it depends on locking files on shared storage, but from my point of view this is bug by design and the mechanism should be redesigned to not rely on client which is actually compute node. It causes many impacts on stability and security of users data!
I want to ask for considering some new cleaning system, because current cleaning worker is designed for indepenent compute nodes without shared storage and it looks like it was not well adapted for configurations with shared storage. Maybe developers should consider some central mechanism and fetching data about used and unused _base files from database, not relying what is running on not on compute node locally.
I can't reproduce this problem anymore because I had to disable cleaning unused base images and deploy own, secure worker.
There's not a lot to go on here, unfortunately. The problem of image cache manager deleting things that are still in use is well known, and in fact we have workarounds elsewhere in the code for it. Out of interest I'd be curious to know how this impacts users, because it also means that the workaround code is broken and/or incomplete.
The underlying problem is obviously image cache manager itself. Without anything more specific to go on I can throw up a patch which fixes a couple of races I was vaguely aware of but hadn't gotten round to addressing. I can't guarantee it will fix your problem, but it might.