[libvirt] image locking?

Itamar Heim Itamar.Heim at qumranet.com
Tue Oct 21 18:22:25 UTC 2008

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)


-----Original Message-----
From: libvir-list-bounces at redhat.com [mailto:libvir-list-bounces at redhat.com] On Behalf Of Perry Myers
Sent: Tuesday, October 21, 2008 15:37 PM
To: Itamar Heim
Cc: libvir-list at 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'. :)


Libvir-list mailing list
Libvir-list at redhat.com

More information about the libvir-list mailing list