RE: [libvirt] image locking?

Hi Perry, The problem is with unreachable hosts which are locking the image forever. When fencing can't be used, there is no way for the management to "release" the image, since it can't verify the host stopped using the image. A leased lock mechanism, while not providing 100% prevention, does allow a collaborative effort to allow releasing the image after the lock expired, by having the nodes check that they still own the lease and stop writing to the images. It would have been much better if image access could have been enforced at storage level, but that is much more complex (and not relevant for images under LVM for example) Itamar -----Original Message----- From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of Perry Myers Sent: Tuesday, October 21, 2008 15:37 PM To: Itamar Heim Cc: libvir-list(a)redhat.com Subject: Re: [libvirt] image locking? In an oVirt network, this shouldn't be a problem. Storage can only be assigned to one VM at a time presently. (In the future we may relax this for clustered filesystems, but shared storage will be marked as such). Regardless of whether or not a VM is active/inactive, once an iSCSI LUN, disk image or otherwise is assigned to a VM it can't be used by other VMs. The storage is not released to the available list until the VM using it is both destroyed and undefined. We don't allow undefine until the VM has been destroyed and we won't confirm that a VM has been destroyed if we can't contact the host that it is running on to confirm. Now... if you start creating VMs on an oVirt network outside of the oVirt Server or decide to share your storage pools between an oVirt network and a non-oVirt network that is problematic. Our solution for that for the time being is 'just don't do that'. :) Perry -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list