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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
