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
