Skip to content

Conversation

@phip1611
Copy link
Member

@phip1611 phip1611 commented Nov 21, 2025

Follow-up of #6974. Please see the commit message for more context.

Our customer/partner confirmed that this solves the problems with NetApp and this is also the same thing that QEMU does. My implementation leaves room for adding --disk lock_granularity=full|byte-range in the future, if one ever needs that.

PS: For now, we at least have testing in our internal test suite for this.

@phip1611 phip1611 requested a review from a team as a code owner November 21, 2025 13:10
@phip1611 phip1611 force-pushed the upstream-disk-lock-byte-ranges branch from 448f234 to 2dca426 Compare November 21, 2025 13:13
The granularity has significant implications in typical cloud
deployments with network storage. The Linux kernel will sync advisory
locks to network file systems, but these backends may have different
policies and handle locks differently. For example, Netapp speaks a NFS
API but will treat advisory OFD locks for the whole file as mandatory
locks, whereas byte-range locks for the whole file will remain
advisory [0].

As it is a valid use case to prevent multiple CHV instances from
accessing the same disk but disk management software (e.g., Cinder in
OpenStack) should be able to snapshot disks while VMs are running, we
need special control over the lock granularity. Therefore, it is a valid
use case to lock the whole byte range of a disk image without
technically locking the whole file - to get the best of both worlds.

This also brings CHVs behavior in line with QEMU [1].

Whole-file locks remain a valid use case and could be supported later.
This patch only provides the necessary groundwork; making it
configurable is out of scope for now.

[0] https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/How_is_Mandatory_Locking_supported_for_NFSv4_on_ONTAP_9
[1] <qemu>/util/osdep.c::qemu_lock_fcntl()

Signed-off-by: Philipp Schuster <[email protected]>
On-behalf-of: SAP [email protected]
@phip1611 phip1611 force-pushed the upstream-disk-lock-byte-ranges branch from 2dca426 to a8086a1 Compare November 21, 2025 13:22
Signed-off-by: Philipp Schuster <[email protected]>
On-behalf-of: SAP [email protected]
Copy link
Member

@rbradford rbradford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

@rbradford rbradford added this pull request to the merge queue Nov 22, 2025
Merged via the queue into cloud-hypervisor:main with commit 16fbab3 Nov 22, 2025
42 of 43 checks passed
@phip1611 phip1611 deleted the upstream-disk-lock-byte-ranges branch November 25, 2025 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants