Bug 817374 - RHEVM - Backend: Failed local domain removal leaves domain in illegal status
RHEVM - Backend: Failed local domain removal leaves domain in illegal status
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
Unspecified Unspecified
high Severity high
: ---
: 3.1.0
Assigned To: Daniel Erez
Daniel Paikov
storage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-29 10:22 EDT by Daniel Paikov
Modified: 2016-02-10 12:00 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-08 04:50:06 EDT
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)
engine.log (66.43 KB, application/x-gzip)
2012-04-29 10:22 EDT, Daniel Paikov
no flags Details

  None (edit)
Description Daniel Paikov 2012-04-29 10:22:26 EDT
Created attachment 581075 [details]
engine.log

* DC with at least 2 data domains.
* Detach/remove non-master domain.
* Initiate failure of removal on VDSM side (my failure happened because domain was in /tmp).
* Backend leaves the domain in Unattached status, which is an illegal status for a local domain.
Comment 1 Daniel Paikov 2012-04-29 10:30:52 EDT
It is then impossible to either attach, activate or remove this domain. The domain basically becomes an orphan domain.
Comment 2 Ayal Baron 2012-08-07 04:38:56 EDT
(In reply to comment #1)
> It is then impossible to either attach, activate or remove this domain. The
> domain basically becomes an orphan domain.

There is a problem with vdsm that it cannot remove the domain.
Can't you *destroy* the storage domain in this case?
Comment 3 Daniel Paikov 2012-08-07 08:12:45 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > It is then impossible to either attach, activate or remove this domain. The
> > domain basically becomes an orphan domain.
> 
> There is a problem with vdsm that it cannot remove the domain.
> Can't you *destroy* the storage domain in this case?

Yes, destroying the domain still works. But the problem is that the backend leaves the domain in a status that shouldn't exist. If you want to implement a logic that destroys Unattached local domains automatically when it can't remove them, then that would be great.
Comment 4 Ayal Baron 2012-08-07 18:52:05 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > It is then impossible to either attach, activate or remove this domain. The
> > > domain basically becomes an orphan domain.
> > 
> > There is a problem with vdsm that it cannot remove the domain.
> > Can't you *destroy* the storage domain in this case?
> 
> Yes, destroying the domain still works. But the problem is that the backend
> leaves the domain in a status that shouldn't exist. If you want to implement
> a logic that destroys Unattached local domains automatically when it can't
> remove them, then that would be great.

Does remove go to vdsm again? (and try again and fail again in this case)
Comment 5 Daniel Paikov 2012-08-08 04:16:53 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > It is then impossible to either attach, activate or remove this domain. The
> > > > domain basically becomes an orphan domain.
> > > 
> > > There is a problem with vdsm that it cannot remove the domain.
> > > Can't you *destroy* the storage domain in this case?
> > 
> > Yes, destroying the domain still works. But the problem is that the backend
> > leaves the domain in a status that shouldn't exist. If you want to implement
> > a logic that destroys Unattached local domains automatically when it can't
> > remove them, then that would be great.
> 
> Does remove go to vdsm again? (and try again and fail again in this case)

Go to vdsm again WHEN? After the first unsuccessful remove? After destroy?
Comment 6 Ayal Baron 2012-08-08 04:47:08 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > (In reply to comment #1)
> > > > > It is then impossible to either attach, activate or remove this domain. The
> > > > > domain basically becomes an orphan domain.
> > > > 
> > > > There is a problem with vdsm that it cannot remove the domain.
> > > > Can't you *destroy* the storage domain in this case?
> > > 
> > > Yes, destroying the domain still works. But the problem is that the backend
> > > leaves the domain in a status that shouldn't exist. If you want to implement
> > > a logic that destroys Unattached local domains automatically when it can't
> > > remove them, then that would be great.
> > 
> > Does remove go to vdsm again? (and try again and fail again in this case)
> 
> Go to vdsm again WHEN? After the first unsuccessful remove? After destroy?

after failed remove.
Point is I do not want to automatically 'destroy' if this is a transient error and I can later try again and remove storage.

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