Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1856826

Summary: Disk upload is failing to resume after pause
Product: [oVirt] ovirt-engine Reporter: Ilan Zuckerman <izuckerm>
Component: BLL.StorageAssignee: Ahmad Khiet <akhiet>
Status: CLOSED DUPLICATE QA Contact: Ilan Zuckerman <izuckerm>
Severity: medium Docs Contact:
Priority: unspecified    
Version: futureCC: aoconnor, bugs, michal.skrivanek, nsoffer, sfishbai, tnisan
Target Milestone: ovirt-4.4.3Keywords: AutomationBlocker, Regression
Target Release: ---Flags: pm-rhel: ovirt-4.4+
aoconnor: blocker-
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-09 05:32:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
transfer with pause logs
none
manual paused reproduction (UI) none

Description Ilan Zuckerman 2020-07-14 14:21:41 UTC
Created attachment 1701045 [details]
transfer with pause logs

Description of problem:

This issue is discovered by automation, making this an automation blocker, but reproduced manually as well.
When pausing and uploading disk permutations (qcow2_v2 / qcow2_v3 / raw) and trying to resume the upload, the disk remains in "paused by system state" which is seen by the UI, or 'locked' state as seen from the logs.

Here we are pausing the upload transfer:

2020-07-12 19:59:18,675+03 INFO  [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-45) [1168f209-8de8-4402-8411-1e4efe959e5a] Transfer was paused by user. Upload disk 'disk_qcow2_v2
_1219574589' (disk id: '8a443238-2fc4-45c5-9dda-cc11d658039d', image id: '25df50aa-cf26-44e7-8c72-06aafe02157b')

Here we attempt to resume it:

2020-07-12 20:00:11,820+03 INFO  [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (default task-15) [f0066986-92f9-44d0-9154-665148bfa6b3] Updating image transfer d7233f8f-7f0c-411a-a92c-208e82a4d507 (image 8a443238-2fc4-45c5-9dda-cc11d658039d) phase to Resuming


The ticket is being renewed:

2020-07-12 20:00:19,074+03 INFO  [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-88) [1168f209-8de8-4402-8411-1e4efe959e5a] Renewing transfer ticket for Upload disk 'disk_qcow2_v2_1219574589' (disk id: '8a443238-2fc4-45c5-9dda-cc11d658039d', image id: '25df50aa-cf26-44e7-8c72-06aafe02157b')


But the transfer is failing to resume due to locked disk:

2020-07-12 20:00:26,234+03 WARN  [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (default task-21) [ba7499d1-40b2-4af4-adb2-1119b2ed2b74] Validation of action 'TransferDiskImage' failed for user admin@internal-authz. Reasons: VAR__TYPE__DISK,VAR__ACTION__TRANSFER,ACTION_TYPE_FAILED_DISKS_LOCKED,$diskAliases disk_qcow2_v2_1219574589
2020-07-12 20:00:26,234+03 INFO  [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (default task-21) [ba7499d1-40b2-4af4-adb2-1119b2ed2b74] Lock freed to object 'EngineLock:{exclusiveLocks='[8a443238-2fc4-45c5-9dda-cc11d658039d=DISK]', sharedLocks='[]'}'
2020-07-12 20:00:26,235+03 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-21) [] Operation Failed: [Cannot transfer Virtual Disk: The following disks are locked: disk_qcow2_v2_1219574589. Please try again in a few minutes.]


On hosts daemon log we only see Timeout reading or writing to socket:

2020-07-12 20:00:11,750 INFO    (Thread-39) [backends.file] Close backend path='/rhev/data-center/mnt/blockSD/e7c18de5-dbc4-466e-934b-02b395b75692/images/8a443238-2fc4-45c5-9dda-cc11d658039d/25df50aa-cf26-44e7-8c72-06aafe02157b' dirty=True
2020-07-12 20:00:11,935 WARNING (Thread-41) [http] Timeout reading or writing to socket: The read operation timed out


On Engine daemon there is "socket.timeout: The read operation timed out" exception:

http://pastebin.test.redhat.com/883594


Version-Release number of selected component (if applicable):
rhv-release-4.4.1-11-001.noarch

How reproducible:
Reproduced by two tier2 automation runs.
Also reproduced manually from the UI

Steps to Reproduce:
    1. Uploads of disk images (raw, qcow2_v3, qcow2_v3, ISO) from localhost
    2. Only If pause is enabled than Reaching 50% upload initiate pause wait
        for a defined timeout & resume uploads
    3. Verify data correctness via md5sum of original and uploaded images

Actual results:
Upload is not resumed after pause.

Expected results:
After resuming, the upload should proceed.

Attaching also logs for a manual reproduction (from the UI)

Comment 1 Ilan Zuckerman 2020-07-14 14:22:23 UTC
Created attachment 1701046 [details]
manual paused reproduction (UI)

Comment 2 RHEL Program Management 2020-07-14 17:11:50 UTC
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Comment 3 Michal Skrivanek 2020-07-14 18:01:15 UTC
ok, pause doesn't work, but regular unpaused upload does, right.
doesn't look like a GA blocker to me, especially with Severity medium

Comment 4 Ahmad Khiet 2020-09-08 08:51:24 UTC
Hi Ilan, 
is there's any error on the UI? or the error is only in the engine logs?

Comment 5 Ahmad Khiet 2020-09-08 08:53:06 UTC
does the bug descriped is like ?
https://bugzilla.redhat.com/show_bug.cgi?id=1828333

Comment 6 Ilan Zuckerman 2020-09-08 09:37:18 UTC
(In reply to Ahmad Khiet from comment #4)
> Hi Ilan, 
> is there's any error on the UI? or the error is only in the engine logs?

Yes, in the ui there is this message:
Uncaught exception occurred. Please try  the page. Details: Exception caught: (TypeError) : Cannot read property 'f' of undefined

BTW, i just tried to reproduce this issue on rhv-4.4.3-2 but the manual scenario (using UI) worked as expected.

Comment 7 Ilan Zuckerman 2020-09-08 09:37:45 UTC
(In reply to Ahmad Khiet from comment #5)
> does the bug descriped is like ?
> https://bugzilla.redhat.com/show_bug.cgi?id=1828333

Yes, looks similar.

Comment 8 Ahmad Khiet 2020-09-08 14:45:35 UTC
(In reply to Ilan Zuckerman from comment #7)
> (In reply to Ahmad Khiet from comment #5)
> > does the bug descriped is like ?
> > https://bugzilla.redhat.com/show_bug.cgi?id=1828333
> 
> Yes, looks similar.

if its similar, then this bug is a duplicate.
the patch for the bug has been merged in 26 Aug 2020.

Comment 9 Ilan Zuckerman 2020-09-09 05:32:11 UTC

*** This bug has been marked as a duplicate of bug 1828333 ***

Comment 10 Ilan Zuckerman 2020-09-09 05:32:40 UTC
(In reply to Ahmad Khiet from comment #8)
> (In reply to Ilan Zuckerman from comment #7)
> > (In reply to Ahmad Khiet from comment #5)
> > > does the bug descriped is like ?
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1828333
> > 
> > Yes, looks similar.
> 
> if its similar, then this bug is a duplicate.
> the patch for the bug has been merged in 26 Aug 2020.

Closed as duplicate.

Comment 11 Sandro Bonazzola 2020-11-06 10:40:46 UTC
Being this closed as duplicate of bug #1828333 and being bug #1828333 closed NEXTRELEASE with target ovirt-4.4.3, re-targeting this bug accordingly.