From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJcGN-0007SV-Q3 for qemu-devel@nongnu.org; Thu, 14 Jan 2016 02:24:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJcGI-0001xX-QB for qemu-devel@nongnu.org; Thu, 14 Jan 2016 02:24:07 -0500 Received: from mx2.parallels.com ([199.115.105.18]:57272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJcGI-0001ux-Jj for qemu-devel@nongnu.org; Thu, 14 Jan 2016 02:24:02 -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> <56949140.1010800@openvz.org> <20160112101031.GB4841@noname.redhat.com> <20160112113331.GA16191@ad.usersys.redhat.com> <569522CF.40504@openvz.org> <20160113001016.GB25517@ad.usersys.redhat.com> <56967ED5.9050300@redhat.com> From: "Denis V. Lunev" Message-ID: <56974CFF.3000904@openvz.org> Date: Thu, 14 Jan 2016 10:23:43 +0300 MIME-Version: 1.0 In-Reply-To: <56967ED5.9050300@redhat.com> Content-Type: text/plain; charset="utf-8"; 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: Eric Blake , Fam Zheng Cc: Kevin Wolf , Olga Krishtal , qemu-devel@nongnu.org, Max Reitz On 01/13/2016 07:44 PM, Eric Blake wrote: > On 01/12/2016 05:10 PM, Fam Zheng wrote: > >>> If we will switch default in my patch from 'nolock' to 'lock' then >>> pour guys which are calling qemu-img etc stuff will see the lock >>> as necessary while 'proper management software' aka libvirt >>> will be able to call qemu/qemu-img etc with proper 'nolock' >>> flag as they do care about the locking. >> That is wrong because then we break old libvirt with the new qemu-img (acquires >> lock by default), which is IMO a breakage of backward compatibility. > In the big software stack picture, it is okay to reject 'old libvirt/new > qemu' as an invalid combination. Upgrade-wise, we specifically support > 'new libvirt/old qemu' - but it is fair game to say that 'if you want to > run new qemu, you must first upgrade to new libvirt that knows how to > drive it'. > > That said, minimizing back-compat breaks, so that old libvirt can > (usually) correctly drive new qemu, is a worthy design goal for qemu. > there is one other thing I have originally missed to add to the picture. Locking could be complex and format specific. In original Parallels disk format (not image but entire bundle), the locking is performed on a very special file. Thus either libvirt must know exact format details or it must rely on something which really does know details, i.e. QEMU/qemu-img. Den