From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJ0ax-0006ws-Lo for qemu-devel@nongnu.org; Tue, 12 Jan 2016 10:10:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJ0av-0002rv-0l for qemu-devel@nongnu.org; Tue, 12 Jan 2016 10:10:51 -0500 References: <1452578622-4492-1-git-send-email-den@openvz.org> <20160112141607.GD4841@noname.redhat.com> From: "Denis V. Lunev" Message-ID: <56951762.9070603@openvz.org> Date: Tue, 12 Jan 2016 18:10:26 +0300 MIME-Version: 1.0 In-Reply-To: <20160112141607.GD4841@noname.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] blk: do not select PFLASH device for internal snapshot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Paolo Bonzini , Laszlo Ersek , qemu-devel@nongnu.org, qemu-block@nongnu.org On 01/12/2016 05:16 PM, Kevin Wolf wrote: > Am 12.01.2016 um 07:03 hat Denis V. Lunev geschrieben: >> There is a long-long story. OVMF VMs can not be snapsotted using >> 'virsh snapshot' as they have "pflash" device which is configured as >> "raw" image. There was a discussion in the past about that. >> >> Good description has been provided on topic by Laszlo Ersek, see below: >> >> "It is true that a pflash drive is "just a drive" *internally* to QEMU. >> It is also true that it more or less takes the same -drive options as >> any other *disk* drive. But those facts are just implementation details. >> >> The relevant trait of pflash storage files is that they are not *disk >> images*, on the libvirt domain XML level. They are not created in >> storage pools, you cannot specify their caching attributes, you don't >> specify their guest-visible frontend in separation (like virtio-blk / >> virtio-scsi / pflash). Those details are hidden (on purpose). >> >> Consequently, pflash storage files are expected to be *small* in size >> (in practice: identically sized to the varstore template they are >> instantiated from). They are created under /var/lib/libvirt/qemu/nvram. >> Although you can edit their path in the domain XML, they are not >> considered disks." >> >> Thus we should avoid selection of "pflash" drives for VM state saving. >> >> For now "pflash" is read-write raw image as it configured by libvirt. >> Thus there are no such images in the field and we could safely disable >> ability to save state to those images inside QEMU. > This is obviously broken. If you write to the pflash, then it needs to > be snapshotted in order to keep a consistent state. > > If you want to avoid snapshotting the image, make it read-only and it > will be skipped even today. > > Kevin you interpret the patch a bit wrong. It will be snapshoted once I'll raw image with qcow2 image, but this image will not be selected for state saving, i.e. it will remain compact. Den