Bug 1879391 - [RFE] Concurrent read of template VM disks fails due to disk lock
Summary: [RFE] Concurrent read of template VM disks fails due to disk lock
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.3.10
Hardware: x86_64
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Benny Zlotnik
QA Contact: Evelina Shames
URL:
Whiteboard:
Depends On: 1677500
Blocks: 1691340 1707372 veritasrhv4.4features
TreeView+ depends on / blocked
 
Reported: 2020-09-16 07:40 UTC by Marian Jankular
Modified: 2023-09-15 01:30 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1677500
Environment:
Last Closed: 2022-05-18 15:00:39 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Marian Jankular 2020-09-16 07:40:54 UTC
Cloning the bug to downstream


+++ This bug was initially created as a clone of Bug #1677500 +++

Description of problem:
In our backup workload, we are trying to read template disks concurrently as we are taking concurrent backup of multiple VMs sharing the same template.
If VMs are dependent clone, while reading template disk using IMAGE IO API, one VM locks the disk and till it is read is over, another process backing up another VM cannot access it.

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


How reproducible:
Create two VMs (VM1, VM2) from template as dependent clones.
Download the all virtual disks for VM1 and start download for VM2 simultaneously. 
Downloading template VM disks for VM2 will fail (initiate transfer API) will fail as disk is already locked.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:

We want to initiate transfer for template disks as these are read only transfer.

Additional info:

--- Additional comment from Daniel Erez on 2019-04-07 10:04:24 UTC ---

@Tal - As the request is to read the same image concurrently, to allow this behaviour,
it would require the introduce some form of a global manager for prepare image 
and teardown image. Thus, as this a major change, I think this should be considered
for a future release. As an alternative, the workaround for this behaviour
should be to download all templates and image layers separately.
Could be done using the 'templates' entity in the API.
I.e. /ovirt-engine/api/templates/<id>/diskattachments

--- Additional comment from Tal Nisan on 2019-04-07 12:46:26 UTC ---

Fair enough, moving to 4.4 and setting as an RFE

--- Additional comment from Eyal Shenitzky on 2020-06-16 08:40:50 UTC ---



--- Additional comment from Avihai on 2020-07-13 14:09:54 UTC ---


According to Daniel E. comment this is a major change

In order to QE_ACK this we need a clear verification scenario.
Can you please provide one?

Is it only this one or is more required ?

1) Create two VMs (VM1, VM2) from template as dependent clones.
2) Download the all virtual disks for VM1 and start download for VM2 simultaneously. 
3) Downloading template VM disks for VM2 will fail (initiate transfer API) will fail as disk is already locked.

--- Additional comment from Tal Nisan on 2020-08-04 11:25:33 UTC ---

Comment 5 Peter Lauterbach 2022-05-18 15:00:39 UTC
Based on the RHV life cycle, we will not be implementing this feature.
https://access.redhat.com/support/policy/updates/rhev

Comment 8 Red Hat Bugzilla 2023-09-15 01:30:35 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days


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