MORITA Kazutaka <morita.kazutaka at gmail.com> writes: > If libsheepdog is used for other applications, it is great. > But the applications may be few in number because of sheepdog restrictions > on data accessing; if vdi is locked, any other client cannot even read the vdi. I guess we're a classic example of someone who'd link to it from a management app. We have a 'cloud infrastructure' management application which currently uses LVM block devices shared over iscsi. As well as allowing end users to attach these block devices to qemu-kvm virtual machines, when they're not in use by a vm, users can GET and PUT block data to them over HTTP, for example uploading a local image in chunks onto the device, or downloading chunks of it. The locking semantics of sheepdog are not too onerous in this application. To be honest, I already enforce similar locking myself at a management level to avoid users corrupting running filesystems or generating inconsistent image downloads. I wonder how expensive it actually is to take and release the lock now? Potentially it could already be quite cheap if corosync performs well and given that dog is now in C... > I wonder whether sheepdog would be more easier to administrate. An additional concern is how painful it can be to get patches into qemu nowadays, given the size of the project, especially getting them backported to the various stable trees. I imagine the sheepdog client protocol and feature-set will be faster moving than qemu's block interface, at least in the short term. Cheers, Chris. |