GitHub user krokodilerian added a comment to the discussion: Shareable RAW disk
Hi, To weigh in here, this is a very dangerous feature and very hard to implement correctly. The use cases I've seen require specific SCSI support from the underlying storage for either "persistent reservations" (Microsoft's cluster shared volumes) or atomics (VMWare VMFS), or other guarantees. Take, for example, the following use case: two VMs (v1 and v2) on two hosts (h1 and h2) have the same disk and use some kind of communication (which is not via the storage) on who does what. Then, h2 loses connectivity to the network and storage but has some operations in flight that are in the queue. There's no mechanism that v2 can use to "cancel" these operations. There's also no way for v1 to know if there are such operations or where they write. So if v1 takes over and the connectivity of h2/v2 is restored, this pretty much guarantees data corruption because the queued old operations will be executed on top of the things v1 has already done. This is solvable with storage or host fencing but would have to be exposed to VMs as an API, which has its own problems. Looking at the oVirt documentation, there's the cop-out "it's the responsibility of the VM to take care of locking," but to reiterate, to be able to do this in a useful way, the guests will need access to low-level SCSI storage functions (or their emulation, like via qemu-pr-helper) or fencing. GitHub link: https://github.com/apache/cloudstack/discussions/9976#discussioncomment-11394967 ---- This is an automatically sent email for users@cloudstack.apache.org. To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org
