Bug 1970792 - Editing VMs based on storage domains in maintenance should not be allowed
Summary: Editing VMs based on storage domains in maintenance should not be allowed
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.4.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: Avihai
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-11 08:53 UTC by Marian Jankular
Modified: 2024-10-01 18:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-04-29 06:51:54 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Marian Jankular 2021-06-11 08:53:33 UTC
Description of problem:
editing guest from storage domains in maintenance should not be allowed, or there should be at least warning that changes will not be reflected in ovf store until the storage domain is activated 

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

How reproducible:
everytime (reproduced myself)

Steps to Reproduce:
1. put SD_A to maintenance
2. edit vm_A setting (disk interface for example) that is stored in SD_A
3. detach the SD_A from the dataceter
4. attach the SD_A to the different or even same DC
5. import vm_A from the SD

Actual results:
changes in step 2 are lost


Expected results:
change should not be either allowed or there should be at least a warning

Additional info:

Comment 1 Arik 2021-06-21 11:32:46 UTC
Generally, when updating VMs/templates the updates may not get to the OVF_STORE "in time" - when the storage domain is not active, when we didn't reach the OVF update, etc
So it really depends what you try to achieve here, maybe OVA would be a better mechanism.
Anyway, import from SD is a storage feature

Comment 4 Michal Skrivanek 2022-04-29 06:51:54 UTC
OVF store is a safety-net mechanism for disaster recovery. It's by design that not all information is available there at all times or in a synchronized way. For transferring individual VMs there's OVA export/import.
Also, missed 4.5. Closing...


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