From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIfci-0002qH-R3 for qemu-devel@nongnu.org; Mon, 11 Jan 2016 11:47:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIfch-0001st-W6 for qemu-devel@nongnu.org; Mon, 11 Jan 2016 11:47:16 -0500 Date: Mon, 11 Jan 2016 17:47:06 +0100 From: Kevin Wolf Message-ID: <20160111164706.GJ9454@noname.redhat.com> References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <20151223031412.GC14423@ad.usersys.redhat.com> <567B2C1F.5030006@redhat.com> <567B8572.4060005@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <567B8572.4060005@parallels.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz Am 24.12.2015 um 06:41 hat Denis V. Lunev geschrieben: > On 12/24/2015 02:19 AM, Max Reitz wrote: > >So the benefits of a qcow2 flag are only minor ones. However, I > >personally believe that automatic unlock on crash is a very minor > >benefit as well. That should never happen in practice anyway, and a > >crashing qemu is such a great inconvenience that I as a user wouldn't > >really mind having to unlock the image afterwards. > IMHO you are wrong. This is VERY important. The situation would be exactly > the same after node poweroff, which could happen and really happens in > the real life from time to time. > > In this cases VMs should start automatically and ASAP if configured this > way. Any manual interaction here is a REAL pain. Yes. Your management tool should be able to cope with it. > >In fact, libvirt could even do that manually, couldn't it? If qemu > >crashes, it just invokes qemu-img force-unlock on any qcow2 image which > >was attached R/W to the VM. > > in the situation above libvirt does not have the information or this > information could be unreliable. That would be a libvirt bug then. Did you check? A good management tool knows which VMs it had running before a host crash. For all I know, libvirt does. Kevin