[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH 00/10] qcow2: Implement image locki
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH 00/10] qcow2: Implement image locking |
Date: |
Mon, 11 Jan 2016 17:47:06 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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