Bug 817374
| Summary: | RHEVM - Backend: Failed local domain removal leaves domain in illegal status | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Daniel Paikov <dpaikov> | ||||
| Component: | ovirt-engine | Assignee: | Daniel Erez <derez> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Daniel Paikov <dpaikov> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 3.1.0 | CC: | abaron, amureini, dyasny, hateya, iheim, lpeer, Rhev-m-bugs, yeylon, ykaul | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 3.1.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | storage | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-08-08 08:50:06 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: |
|
||||||
It is then impossible to either attach, activate or remove this domain. The domain basically becomes an orphan domain. (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? (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. (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) (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? (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. |
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.