qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks.
Date: Tue, 15 Dec 2009 12:02:04 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Richard W.M. Jones wrote:
This is v3 of the lock patch, previously discussed here:

http://lists.gnu.org/archive/html/qemu-devel/2009-12/threads.html#00461

In this version I've reverted back to the simpler interface.  There is
now only one "lock" option, which can be lock=exclusive|shared|none.

At Kevin Wolf's suggestion,
lock=exclusive|shared => all backing disks are locked shared
lock=none => no locks are acquired on any front or back disks

I don't quite understand why we need exclusive|shared as opposed to just 'on'. Can you enumerate the use-cases associated with exclusive and shared?

In order to mitigate the problem with locks during live migration,
I've added a lock command to the monitor, which currently allows you
to acquire (but not revoke) a lock.  (Revocation could be added fairly
easily too.)  This should allow the management tool to start the qemu
destination process without locking, and lock it once migration is
complete.

I really dislike this as an interface. I think we need to make a decision about whether we delay open until after migration has completed. I think unless there's a really compelling argument against it, this is probably what we should do.

As it stands, we cannot make lock=!none the default if it takes an extra monitor command to allow for live migration. I think if we're going to introduce this functionality, we probably should be enabling it by default.

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]