From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJ0sN-0006eR-LR for qemu-devel@nongnu.org; Tue, 12 Jan 2016 10:28:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJ0sM-00085C-FE for qemu-devel@nongnu.org; Tue, 12 Jan 2016 10:28:51 -0500 Date: Tue, 12 Jan 2016 16:28:43 +0100 From: Kevin Wolf Message-ID: <20160112152843.GI4841@noname.redhat.com> References: <1452578622-4492-1-git-send-email-den@openvz.org> <20160112141607.GD4841@noname.redhat.com> <56951762.9070603@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56951762.9070603@openvz.org> 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: "Denis V. Lunev" Cc: Paolo Bonzini , Laszlo Ersek , qemu-devel@nongnu.org, qemu-block@nongnu.org Am 12.01.2016 um 16:10 hat Denis V. Lunev geschrieben: > 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. Sorry, I misunderstood. That's more reasonable indeed. Kevin