cloud-hypervisor
Expose disk lock granularity as a user-configurable option
Cloud Hypervisor recently merged PR #7494, which switches from whole-file OFD locks to byte-range advisory locks over the full disk size. This change improves compatibility with NetApp storage systems, where whole-file OFD locks are interpreted as mandatory but byte-range locks retain advisory semantics. The implementation also intentionally leaves room for a future configuration knob to select the lock granularity.
Different environments may prefer different lock semantics:
Default (byte-range) works best for storage backends like NetApp, matching QEMU behavior and maintaining advisory-lock semantics.
Whole-file locking might still be desirable for environments that rely on the traditional OFD whole-file lock behavior.
Some users may also want to disable advisory locking entirely or run in warn-only mode (supported today via lock=off|warn|on).
Right now Cloud Hypervisor internally uses byte-range locks for all disks, but users cannot opt back into the previous whole-file behavior if their infrastructure depends on it.
I'd introduce an optional per-disk parameter, for example:
--disk path=/foo.img,lock_granularity=byte-range
--disk path=/bar.img,lock_granularity=full
With the following semantics:
byte-range(default) Locks [0, size) via OFD byte-range locking.fullUses the original whole-file OFD lock (l_start=0, l_len=0).
This would map cleanly to the existing LockGranularity enum introduced in PR #7494 and require only limited plumbing through the config layer down to virtio-devices.
Is that sounds good, I can work on the implementation.
whole-file behavior if their infrastructure depends on it.
Do you have a specific case where you need this for? Or do you want to create the necessary flexibility for the future?
run in warn-only mode (supported today via lock=off|warn|on).
This is not true at all. Why do you think that? 🤔 There was once a discussion about this but we rejected that in favor of a mature implementation handling all cases correctly (such as live migration).
I'm even strongly against a warn semantics or even turning locking off as it opens the door to misconfiguration and silent data corruption. I don't see scenarios where this is desired.
In case you have very strong evidence that we should have that, I'm of course open for your argumentation.
lock_granularity=byte-range|full
sound very reasonable to me as I already mentioned in #7494 which you also quoted :)
Do you have a specific case where you need this for? Or do you want to create the necessary flexibility for the future?
Mainly flexibility for the future, and also because I want to start contributing to CH 🙂
This is not true at all. Why do you think that?...
I didn’t mean to suggest that lock=off|warn|on exists in Cloud Hypervisor today. I mixed that up with an older discussion and with how QEMU behaves. The only thing I want to work on is adding lock_granularity=byte-range|full.
sounds very reasonable to me as I already mentioned in https://github.com/cloud-hypervisor/cloud-hypervisor/pull/7494 which you also quoted :)
Great, I’ll start working on the implementation then 👍
want to start contributing to CH 🙂
Highly appreciated 🚀 we're looking forward to your contribution and are happy to review and assist