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