ср, 16 февр. 2022 г. в 11:58, Peter Krempa <pkrempa@xxxxxxxxxx>:
On Wed, Feb 16, 2022 at 11:38:01 +0300, Nikolay Shirokovskiy wrote:
> Currently taking an internal inactive snapshot with a disk excluded from
> snapshot using snapshot="no" will fail with error "Disk device '%s' does
> not support snapshotting".
The idea for internal snapshots since we wanted them to behave the same
as they do with 'savevm' is that you can't actually exclude a disk from
the snapshot.
Could you elaborate how you expect this to co-operate with live internal
snapshots?
I have an issue with readonly usb raw disk. Making internal snapshot of an active domain
is possible in this case if I exclude the disk from snapshot explicitly or implicitly.
However in case of inactive domain snapshot fails with the above error. So I guess
we should allow this case.
So maybe we should check for readonly property of the disk instead? On snapshot creation
there will be no difference as check in virDomainSnapshotAlignDisks will fail for non
readonly disks. Yet it makes more sense to me to check snapdef disk because qemuDomainSnapshotForEachQcow2Raw
is only to call qemu-img and the decision about the disk set is not its concern. Also
the function is used on snapshot reverting/deletion and we want to base
on snapdef again and not the current state of readonly attribute on disk.
However it is not clear to me why there should be parity between active and inactive
snapshot in terms of possible disk sets. We have constraint on set in case of active
snapshot just due to API limitations. What are the reasons to mimic this set for inactive
snapshot?
Nikolay
