[libvirt] using sync_manager with libvirt

Perry Myers pmyers at redhat.com
Wed Aug 18 23:44:18 UTC 2010


On 08/11/2010 05:27 PM, Daniel P. Berrange wrote:
> On Wed, Aug 11, 2010 at 03:37:12PM -0400, David Teigland wrote:
>> On Wed, Aug 11, 2010 at 05:59:55PM +0100, Daniel P. Berrange wrote:
>>> On Tue, Aug 10, 2010 at 12:44:06PM -0400, David Teigland wrote:
...
>>> There's two different, but related problems here:
>>>
>>>  - Preventing 2 different VMs using the same disk
>>>  - Preventing the same VM running on 2 hosts at once
>>>
>>> The first requires that there is a lease per configured disk (since
>>> a guest can have multiple disks). The latter requires a lease per
>>> VM and can ignore specifices of what disks are configured.
>>>
>>> IIUC, sync-manager is aiming for the latter.

If we only aim for the latter, then there is no protection mechanism to
prevent two sysadmins using the same storage from independently creating
two vms that use the same backend disk accidentally.

On the other hand, we also need to be able to support the concept of a
single block device shared among multiple guests intentionally (i.e.
clustered filesystems, or applications that know how to properly use
shared storage)

So in addition to per-disk exclusive-write leases, do we also need
per-disk shared-write leases?  Or do we just say that disks that are
marked as 'shared' just don't get leases at all?

>> The present integration effort is aiming for the latter.  sync_manager
>> itself aims to be agnostic about what it's managing.
> 
> Ok, it makes a bit of a difference to how we integrate with
> it in libvirt. If we want to ever let sync-manager do per-disk
> leases then we'd want to pass more info to the SM callbacks
> so it knows what disks QEMU has, instead of just its name

I dunno, but if the end goal is the latter, then why not do it correct
from the start rather than integrating halfway and then having a second
round of integration to move from per-vm leasing to per-disk leasing.

Perry




More information about the libvir-list mailing list