Bug 1569479 - Snapshot with memory when not all disks are included
Summary: Snapshot with memory when not all disks are included
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-19 11:18 UTC by Milan Zamazal
Modified: 2018-11-21 00:19 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-11-21 00:19:10 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.3+


Attachments (Terms of Use)

Description Milan Zamazal 2018-04-19 11:18:45 UTC
Description of problem:

When a VM snapshot with memory is created and not all disks are included in it, various problems can happen. What if a non-included disk is modified in the meantime? What if a disk operation on it was running when making the snapshot? What if the disk gets removed before resuming the snapshot? One particular problem with starting snapshot preview is described below.

It's true that users are warned when making such a snapshot. But it's difficult to find a reasonable use case in any case. So it would be probably best not to allow saving memory when not all disks are included. Snapshot without memory should be appropriate in such a case.

Version-Release number of selected component (if applicable):

oVirt 4.3 (master)

How reproducible:

Always.

Steps to Reproduce:
1. Start a VM with more than one disk.
2. Create a snapshot of the VM, check "Save Memory" and uncheck one of the disks.
3. Stop the VM.
4. Remove the disk not included in the snapshot.
5. Preview the snapshot.
6. Run the VM.

Actual results:

The VM snapshot preview can't be started.

Expected results:

"Save Memory" option should be disabled and set off when making a snapshot with not all disks included.

Additional info:

Perhaps a configuration option could be provided to retain the original (semi-broken) behavior.

Comment 1 Yaniv Kaul 2018-04-26 09:59:48 UTC
Severity?

Comment 2 Michal Skrivanek 2018-04-26 10:07:15 UTC
it can be avoided by following the warning and including all disks.
When it is configured like that you can get easily to a state when the snapshot cannot start or starts in a wrong way - potentially corrupting the resumed state (say, in-flight I/O to a disk which is not included in the restore, unexpected HW configuration change)

But since this is a existing behavior for a long time it's not that common.

Comment 3 Ryan Barry 2018-11-21 00:19:10 UTC
Closing due to capacity. It's an unusual workflow which hasn't generated an additional bug report in years (despite being an actual bug)


Note You need to log in before you can comment on or make changes to this bug.