Bug 1577926

Summary: Moving host to maintenance mode failed
Product: [oVirt] ovirt-engine Reporter: Dor <dpinhas>
Component: BLL.StorageAssignee: Daniel Erez <derez>
Status: CLOSED DUPLICATE QA Contact: Elad <ebenahar>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.2.3.5CC: bugs, dpinhas
Target Milestone: ovirt-4.3.0Flags: rule-engine: ovirt-4.3+
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-03 10:53:19 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
engine log
none
vdsm log
none
full engine log none

Description Dor 2018-05-14 12:39:19 UTC
Description of problem:
When trying to move a host into a maintenance mode, the bellow error appeared.

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

How reproducible:
Enter a host into a maintenance mode

Steps to Reproduce:
1.
2.
3.

Actual results:
Error while executing action: Cannot switch Host buri06 to Maintenance mode. Image transfer is in progress for the following (1) disks: 
e084c73a-c804-49ba-bdf4-39065a508bfe 
Please wait for the operations to complete and try again.

Expected results:


Additional info:

Comment 1 Tal Nisan 2018-05-14 13:35:12 UTC
Dor, the error is quite clear, why is it a bug? 
You have disk transfer going on, either wait for it to finish or cancel it so you can move the host to maintenance

Comment 2 Dor 2018-05-14 13:49:53 UTC
Sorry about that misinfo
I'm not seeing any ongoing disk transfer
plus, the mentioned disk-id cannot be found in the disks page

Comment 3 Tal Nisan 2018-05-14 13:51:07 UTC
Please attach Engine logs and VDSM logs for the host you are trying to move to maintenance

Comment 4 Dor 2018-05-14 13:58:24 UTC
Created attachment 1436207 [details]
engine log

Comment 5 Dor 2018-05-14 13:58:49 UTC
Created attachment 1436212 [details]
vdsm log

Comment 6 Tal Nisan 2018-05-21 11:37:12 UTC
Daniel, I've logged into the apartment, I couldn't see any disk transferring in the UI nor could I find any disk with this ID.
I logged into the DB to search for active transfer and I've found 11 transfers there, one of them is the aforementioned one, can you please work with Dor and have a look why this transfer blocks the host from moving into maintenance?

Comment 7 Daniel Erez 2018-05-21 12:01:45 UTC
(In reply to Tal Nisan from comment #6)
> Daniel, I've logged into the apartment, I couldn't see any disk transferring
> in the UI nor could I find any disk with this ID.
> I logged into the DB to search for active transfer and I've found 11
> transfers there, one of them is the aforementioned one, can you please work
> with Dor and have a look why this transfer blocks the host from moving into
> maintenance?

@Dor - can you please attach full engine logs (to understand why the image transfers remained active). Also, in which engine version have these transfers initiated at?

Comment 8 Dor 2018-05-21 13:40:07 UTC
Created attachment 1439618 [details]
full engine log

Comment 9 Dor 2018-05-21 13:41:52 UTC
Added the logs, im not sure when this initiated but the current version is 4.2.3.5

Comment 10 Daniel Erez 2018-05-28 07:06:39 UTC
(In reply to Dor from comment #9)
> Added the logs, im not sure when this initiated but the current version is
> 4.2.3.5

Seems the attached engine log doesn't contain any info on TransferDiskImageCommand execution, so they probably were initiated from an old build. Is the previous log (before upgrade) still exists?

Comment 11 Dor 2018-07-02 11:06:59 UTC
Daniel,

We have a previous logs but I don't really know when this was upgraded and to which version.
We're upgrading the engine occasionally, every beta release or so.

Comment 12 Daniel Erez 2018-09-03 10:53:19 UTC
Should be fixed as part of bug 1586126, closing as duplicate.

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