Bug 843407 - ovirt-engine-backend [TEXT]: wrong error message when trying to reconstruct master during remove/create volume actions
ovirt-engine-backend [TEXT]: wrong error message when trying to reconstruct m...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
x86_64 Linux
medium Severity low
: ---
: 3.1.0
Assigned To: Greg Padgett
Dafna Ron
storage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-26 04:58 EDT by Dafna Ron
Modified: 2016-02-10 11:30 EST (History)
11 users (show)

See Also:
Fixed In Version: SI20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 15:00:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log (125.43 KB, application/x-xz)
2012-07-26 04:58 EDT, Dafna Ron
no flags Details

  None (edit)
Description Dafna Ron 2012-07-26 04:58:26 EDT
Created attachment 600460 [details]
log

Description of problem:

we are getting the following error: 

2012-07-26 11:43:54,658 WARN  [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (ajp-/0.0.0.0:8009-7) CanDoAction of action DeactivateStorageDomain failed. Reasons:VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__DEACTIVATE,ACTION_TYPE_FAILED_DETECTED_RUNNING_VMS


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

si11

How reproducible:

70%

Steps to Reproduce:
1. reconstruct master domain while there are running tasks (such as create vm's, remove vm's)
2.
3.
  
Actual results:

if we block the reconstruct *which does not happen each time because of a race bug, than we are getting a wrong error message that there are running vms

Expected results:

we should rephrase error 

Additional info: backend log
Comment 1 Sharad Mishra 2012-07-30 17:47:44 EDT
Trying to understand what the issue is here. 

Currently the code flow is - 

        if (!getParameters().getIsInternal()
                && !getVmDAO()
                        .getAllRunningForStorageDomain(getStorageDomain().getId())
                        .isEmpty()) {
            addCanDoActionMessage(VdcBllMessages.ACTION_TYPE_FAILED_DETECTED_RUNNING_VMS);
            return false;
        }
        if (getStoragePool().getspm_vds_id() != null
                    && getStorageDomain().getstorage_domain_type() != StorageDomainType.ISO
                    && getAsyncTaskDao().getAsyncTaskIdsByEntity(getParameters().getStorageDomainId()).size() > 0) {
                addCanDoActionMessage(VdcBllMessages.ERROR_CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS);
                return false;
        }

If we reverse it and check for tasks before running VMs. Will it solve this issue without creating any new one?
Comment 2 Dafna Ron 2012-09-12 05:29:48 EDT
(In reply to comment #1)
> Trying to understand what the issue is here. 
> 
> Currently the code flow is - 
> 
>         if (!getParameters().getIsInternal()
>                 && !getVmDAO()
>                        
> .getAllRunningForStorageDomain(getStorageDomain().getId())
>                         .isEmpty()) {
>            
> addCanDoActionMessage(VdcBllMessages.
> ACTION_TYPE_FAILED_DETECTED_RUNNING_VMS);
>             return false;
>         }
>         if (getStoragePool().getspm_vds_id() != null
>                     && getStorageDomain().getstorage_domain_type() !=
> StorageDomainType.ISO
>                     &&
> getAsyncTaskDao().getAsyncTaskIdsByEntity(getParameters().
> getStorageDomainId()).size() > 0) {
>                
> addCanDoActionMessage(VdcBllMessages.
> ERROR_CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS);
>                 return false;
>         }
> 
> If we reverse it and check for tasks before running VMs. Will it solve this
> issue without creating any new one?



it was two months ago, but I don't think that there were running vm's. 
so the first CanDoAction should not have been fired.
Comment 3 Greg Padgett 2012-09-13 18:24:42 EDT
http://gerrit.ovirt.org/7997

(In reply to comment #2)
> it was two months ago, but I don't think that there were running vm's. 
> so the first CanDoAction should not have been fired.

The root cause is that some tasks cause the VMs to appear "running" even if they aren't, according to getAllRunningForStorageDomain--the stored procedure that backs it looks for VMs that aren't in the "Down" state--which includes not only those that are running, but also those that are migrating, locked, etc.

(In reply to comment #1)
> If we reverse it and check for tasks before running VMs. Will it solve this
> issue without creating any new one?

Depends... there still may be cases where there are no tasks, yet the VM is in such a state as to appear running.  Instead, I've generalized the message so it is more clear what is going on.
Comment 5 Allon Mureinik 2012-09-29 08:48:07 EDT
Merged I3ce9ce378ffeed980af508e6556f9d844a3e07bd
Comment 7 Dafna Ron 2012-10-15 12:24:49 EDT
verified on si20

Error while executing action: Cannot deactivate Master Data Domain while there are running tasks on its Data Center.
-Please wait until tasks will finish and try again.

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