From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJHTg-0002tI-7H for qemu-devel@nongnu.org; Wed, 13 Jan 2016 04:12:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJHTb-0007zh-HL for qemu-devel@nongnu.org; Wed, 13 Jan 2016 04:12:28 -0500 Received: from relay.parallels.com ([195.214.232.42]:50212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJHTb-0007za-9Y for qemu-devel@nongnu.org; Wed, 13 Jan 2016 04:12:23 -0500 References: <567A4EB0.1040807@parallels.com> <1450856816-9816-1-git-send-email-den@openvz.org> <1450856816-9816-2-git-send-email-den@openvz.org> <20160111173106.GL9454@noname.redhat.com> <20160111175855.GC29228@redhat.com> <20160111183557.GN9454@noname.redhat.com> <87pox5oo8f.fsf@blackfin.pond.sub.org> From: "Denis V. Lunev" Message-ID: <569614EA.2020608@openvz.org> Date: Wed, 13 Jan 2016 12:12:10 +0300 MIME-Version: 1.0 In-Reply-To: <87pox5oo8f.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Kevin Wolf Cc: Fam Zheng , Olga Krishtal , qemu-devel@nongnu.org, Max Reitz On 01/13/2016 11:52 AM, Markus Armbruster wrote: > Kevin Wolf writes: > >> Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben: >>> On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote: >>>> Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben: >>>>> From: Olga Krishtal >>>>> >>>>> While opening the image we want to be sure that we are the >>>>> one who works with image, anf if it is not true - >>>>> opening the image for writing should fail. >>>>> >>>>> There are 2 ways at the moment: no lock at all and lock the file >>>>> image. >>>>> >>>>> Signed-off-by: Olga Krishtal >>>>> Signed-off-by: Denis V. Lunev >>>>> CC: Kevin Wolf >>>>> CC: Max Reitz >>>>> CC: Eric Blake >>>>> CC: Fam Zheng >>>> As long as locking is disabled by default, it's useless and won't >>>> prevent people from corrupting their images. These corruptions happen >>>> exactly because people don't know how to use qemu properly. You can't >>>> expect them to enable locking manually. >>>> >>>> Also, you probably need to consider bdrv_reopen() and live migration. >>>> I think live migration would be blocked if source and destination both >>>> see the lock; which is admittedly less likely than with the qcow2 patch >>>> (and generally a problem of this series), but with localhost migration >>>> and potentially with some NFS setups it can be the case. >>> Note that when libvirt does locking it will release locks when a VM >>> is paused, and acquire locks prior to resuming CPUs. This allows live >>> migration to work because you never have CPUs running on both src + dst >>> at the same time. This does mean that libvirt does not allow QEMU to >>> automatically re-start CPUs when migration completes, as it needs to >>> take some action to acquire locks before allowing the dst to start >>> running again. >> This assumes that block devices can only be written to if CPUs are >> running. In the days of qemu 0.9, this was probably right, but with >> things like block jobs and built-in NBD servers, I wouldn't be as sure >> these days. > Sounds like QEMU and libvirt should cooperate more closely to get the > locking less wrong. > > QEMU should have more accurate knowledge on how it is using the image. > Libvirt may be able to provide better locks, with the help of its > virtlockd daemon. daemon owning locks is a problem: - there are distributed cases - daemons restart from time to time