On Tue, Dec 08, 2009 at 10:48:17AM +0100, Kevin Wolf wrote:
> Am 07.12.2009 15:31, schrieb Richard W.M. Jones:
> > So to be clear, the use case is that all the other VMs must be shut
> > down, then the VM which wants to commit will upgrade its lock and
> > commit, and then all the other VMs will re
Am 07.12.2009 15:31, schrieb Richard W.M. Jones:
> On Mon, Dec 07, 2009 at 08:22:24AM -0600, Anthony Liguori wrote:
>> Richard W.M. Jones wrote:
>>> On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
>>>
Richard W.M. Jones wrote:
> Also if we only acquire the loc
Am 07.12.2009 15:53, schrieb Anthony Liguori:
> Daniel P. Berrange wrote:
>> It is safe if you assume that no one else has tried to modify the disk
>> since you opened it, otherwise you'd be commiting changes against a
>> base state which no longer exists.
>
> 1) first user opens cow1.qcow, acqui
"Daniel P. Berrange" writes:
> The only other alternative would be for the destination to open the disks,
> but not immediately acquire the locks. In the final stage of migration have
> the source release its lock & signal to the dest that it can now acquire
> the lock. The assumption being that
Richard W.M. Jones wrote:
So to be clear, the use case is that all the other VMs must be shut
down, then the VM which wants to commit will upgrade its lock and
commit, and then all the other VMs will restart? I agree this should
avoid corruption, although it sounds like something which is fairly
Daniel P. Berrange wrote:
It is safe if you assume that no one else has tried to modify the disk
since you opened it, otherwise you'd be commiting changes against a
base state which no longer exists.
1) first user opens cow1.qcow, acquires F_WRLCK
2) first user opens base.qcow, acquires F_RDLC
On Mon, Dec 07, 2009 at 08:22:24AM -0600, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
>> On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
>>
>>> Richard W.M. Jones wrote:
>>>
Also if we only acquire the lock during the commit operation then
we'll end up with
On Mon, Dec 07, 2009 at 08:15:51AM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >>Better to stick with on/off. That gives much easier to understand
> >>semantics.
> >>
> >
> >The 3rd invocation is not changing the backing file, so it is not causing
> >data corruption on the mas
On Mon, Dec 07, 2009 at 07:32:16AM -0600, Anthony Liguori wrote:
> Chris Webb wrote:
> >Hi. There's a connected discussion on the sheepdog list about locking, and
> >I
> >have a patch there which could complement this one quite well.
> >
> >Sheepdog is a distributed, replicated block store being d
Richard W.M. Jones wrote:
On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Also if we only acquire the lock during the commit operation then
we'll end up with disk corruption.
Why do we end up with disk corruption?
Forget about lo
Daniel P. Berrange wrote:
Better to stick with on/off. That gives much easier to understand
semantics.
The 3rd invocation is not changing the backing file, so it is not causing
data corruption on the master file. Sure the 3rd OS instance will probably
crash & get confused because its back
On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
>> Also if we only acquire the lock during the commit operation then
>> we'll end up with disk corruption.
>
> Why do we end up with disk corruption?
Forget about locking for a minute, I don't think this i
On Mon, Dec 07, 2009 at 07:43:53AM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >That doesn't work in the case of setting up a clustered filesystem
> >shared between guests. That requires that the disk be opened writable,
> >but with a shared (F_RDLOCK) lock.
> >
>
> If you'd like
Chris Webb wrote:
Anthony Liguori writes:
I've resisted this because I'm concerned that if we delay the
opening of the file on the destination, it could fail. That's a
very late failure and that makes me uncomfortable as just a work
around for NFS.
I don't know much about NFS's sema
Daniel P. Berrange wrote:
That doesn't work in the case of setting up a clustered filesystem
shared between guests. That requires that the disk be opened writable,
but with a shared (F_RDLOCK) lock.
If you'd like data corruption :-)
qemu -drive file=/dev/hda,lock=shared # clustered file s
Richard W.M. Jones wrote:
On Sat, Dec 05, 2009 at 11:47:11AM -0600, Anthony Liguori wrote:
I think I made my point poorly. Consider the following:
qemu-img create -f raw base.img 10G
qemu-img create -f qcow2 -b base.img cow1.img
qemu-img create -f qcow2 -b base.img cow2.img
qemu -drive fil
Anthony Liguori writes:
> I've resisted this because I'm concerned that if we delay the
> opening of the file on the destination, it could fail. That's a
> very late failure and that makes me uncomfortable as just a work
> around for NFS.
I don't know much about NFS's semantics with cache-coher
Chris Webb wrote:
Hi. There's a connected discussion on the sheepdog list about locking, and I
have a patch there which could complement this one quite well.
Sheepdog is a distributed, replicated block store being developed
(primarily) for Qemu. Images have a mandatory exclusive locking requirem
On Mon, Dec 07, 2009 at 11:28:34AM +, Jamie Lokier wrote:
> Kevin Wolf wrote:
> > Am 07.12.2009 11:31, schrieb Jamie Lokier:
> > > So the distinction read/write makes more sense. Can anyone think of a
> > > situation where a shared lock on an image opened for writing is useful?
> >
> > I thin
On Mon, Dec 07, 2009 at 11:49:32AM +, Daniel P. Berrange wrote:
> On Mon, Dec 07, 2009 at 11:31:47AM +, Richard W.M. Jones wrote:
> > On Mon, Dec 07, 2009 at 11:30:14AM +, Daniel P. Berrange wrote:
> > > On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
> > > >
> > > > No,
Am 07.12.2009 12:28, schrieb Jamie Lokier:
> Kevin Wolf wrote:
>> Am 07.12.2009 11:31, schrieb Jamie Lokier:
>>> So the distinction read/write makes more sense. Can anyone think of a
>>> situation where a shared lock on an image opened for writing is useful?
>>
>> I think there are people using sh
On Mon, Dec 07, 2009 at 11:31:47AM +, Richard W.M. Jones wrote:
> On Mon, Dec 07, 2009 at 11:30:14AM +, Daniel P. Berrange wrote:
> > On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
> > >
> > > No, the question is whether it makes sense to provide a 'shared'
> > > option on t
Richard W.M. Jones wrote:
> > That doesn't work in the case of setting up a clustered filesystem
> > shared between guests. That requires that the disk be opened writable,
> > but with a shared (F_RDLOCK) lock.
>
> I think Jamie's point is that you might as well use no locking at all
> in this con
Richard W.M. Jones wrote:
> On Sat, Dec 05, 2009 at 11:47:11AM -0600, Anthony Liguori wrote:
> > I think I made my point poorly. Consider the following:
> >
> > qemu-img create -f raw base.img 10G
> > qemu-img create -f qcow2 -b base.img cow1.img
> > qemu-img create -f qcow2 -b base.img cow2.img
>
On Mon, Dec 07, 2009 at 11:30:14AM +, Daniel P. Berrange wrote:
> On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
> > Daniel P. Berrange wrote:
> > > > Sometimes shared access to a raw image (partitioned or whole disk
> > > > filesystem) is ok, and sometimes it is not ok. Only th
On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
> Daniel P. Berrange wrote:
> > > Sometimes shared access to a raw image (partitioned or whole disk
> > > filesystem) is ok, and sometimes it is not ok. Only the user knows
> > > the difference, because only the user knows if the guests
Kevin Wolf wrote:
> Am 07.12.2009 11:31, schrieb Jamie Lokier:
> > So the distinction read/write makes more sense. Can anyone think of a
> > situation where a shared lock on an image opened for writing is useful?
>
> I think there are people using shared writable images with cluster file
> system
Daniel P. Berrange wrote:
> > Sometimes shared access to a raw image (partitioned or whole disk
> > filesystem) is ok, and sometimes it is not ok. Only the user knows
> > the difference, because only the user knows if the guests they are
> > running use distinct partitions in the same raw image, o
On Mon, Dec 07, 2009 at 10:31:28AM +, Jamie Lokier wrote:
> Anthony Liguori wrote:
> > I'm not sure whether it's best to enable it by default because, as I
> > said earlier, I'm not comfortable with the lack of correctness wrt
> > advisory vs. mandatory locking.
>
> In my experience, disk im
On Sat, Dec 05, 2009 at 11:47:11AM -0600, Anthony Liguori wrote:
> I think I made my point poorly. Consider the following:
>
> qemu-img create -f raw base.img 10G
> qemu-img create -f qcow2 -b base.img cow1.img
> qemu-img create -f qcow2 -b base.img cow2.img
>
> qemu -drive file=cow1.img,lock=excl
Am 07.12.2009 11:48, schrieb Avi Kivity:
> On 12/07/2009 12:42 PM, Kevin Wolf wrote:
>> I think there are people using shared writable images with cluster file
>> systems.
>>
>
> Hopefully not with qcow2.
Right, it doesn't make sense with all of the image formats. But it does
with some of the
On 12/07/2009 12:42 PM, Kevin Wolf wrote:
I think there are people using shared writable images with cluster file
systems.
Hopefully not with qcow2.
--
error compiling committee.c: too many arguments to function
On Mon, Dec 07, 2009 at 10:31:28AM +, Jamie Lokier wrote:
> Anthony Liguori wrote:
> > I'm not sure whether it's best to enable it by default because, as I
> > said earlier, I'm not comfortable with the lack of correctness wrt
> > advisory vs. mandatory locking.
>
> In my experience, disk im
Am 07.12.2009 11:31, schrieb Jamie Lokier:
> So the distinction read/write makes more sense. Can anyone think of a
> situation where a shared lock on an image opened for writing is useful?
I think there are people using shared writable images with cluster file
systems.
Kevin
Hi. There's a connected discussion on the sheepdog list about locking, and I
have a patch there which could complement this one quite well.
Sheepdog is a distributed, replicated block store being developed
(primarily) for Qemu. Images have a mandatory exclusive locking requirement,
enforced by the
Anthony Liguori wrote:
> I'm not sure whether it's best to enable it by default because, as I
> said earlier, I'm not comfortable with the lack of correctness wrt
> advisory vs. mandatory locking.
In my experience, disk images are accessed in one of five ways:
qemu-img
qemu
qemu-nbd
On Fri, Dec 04, 2009 at 11:15:12AM -0600, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
> >[from the commit message ...]
> >
> >Allow qemu to acquire shared and exclusive locks on disk images.
> >This is done by extending the -drive option with an additional,
> >optional parameter:
> >
> > -d
Avi Kivity wrote:
I think I made my point poorly. Consider the following:
qemu-img create -f raw base.img 10G
qemu-img create -f qcow2 -b base.img cow1.img
qemu-img create -f qcow2 -b base.img cow2.img
qemu -drive file=cow1.img,lock=exclusive
qemu -drive file=cow2.img,lock=exclusive
With the
On 12/05/2009 07:47 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/05/2009 12:29 AM, Anthony Liguori wrote:
Well disk sharing isn't actually bad as long as it's raw or a
physical device.
For qcow2, it's very complicated by backing files because we really
need to express the concept of
Avi Kivity wrote:
On 12/05/2009 12:29 AM, Anthony Liguori wrote:
Well disk sharing isn't actually bad as long as it's raw or a
physical device.
For qcow2, it's very complicated by backing files because we really
need to express the concept of a read-write lock.
That is, as long as the gue
On 12/05/2009 12:29 AM, Anthony Liguori wrote:
Well disk sharing isn't actually bad as long as it's raw or a physical
device.
For qcow2, it's very complicated by backing files because we really
need to express the concept of a read-write lock.
That is, as long as the guests are opening the
Richard W.M. Jones wrote:
The idea would be for management tools (eg. libvirt) to add the lock
parameter for all virtual machines that they manage.
I don't see how this is worse than what we have now -- ie. no
possibility of locking at all and a very real risk of disk corruption.
Anyway, we cou
On Fri, Dec 04, 2009 at 11:15:12AM -0600, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
>> [from the commit message ...]
>>
>> Allow qemu to acquire shared and exclusive locks on disk images.
>> This is done by extending the -drive option with an additional,
>> optional parameter:
>>
>> -dri
Richard W.M. Jones wrote:
[from the commit message ...]
Allow qemu to acquire shared and exclusive locks on disk images.
This is done by extending the -drive option with an additional,
optional parameter:
-drive [...],lock=none
-drive [...],lock=shared
-drive [...],lock=exclusive
lock=no
[from the commit message ...]
Allow qemu to acquire shared and exclusive locks on disk images.
This is done by extending the -drive option with an additional,
optional parameter:
-drive [...],lock=none
-drive [...],lock=shared
-drive [...],lock=exclusive
lock=none is the default, and it me
45 matches
Mail list logo
