qemu-block
[Top][All Lists]
Advanced

[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



reply via email to

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