Bug 823686 - [rhevm] unable to detach storage domain after moving all vms and coping all templates - improve error message [TEXT]
[rhevm] unable to detach storage domain after moving all vms and coping all t...
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.0.3
x86_64 Linux
unspecified Severity high
: ---
: 3.2.0
Assigned To: Daniel Erez
Haim
storage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-21 17:39 EDT by Haim
Modified: 2016-02-10 12:08 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Release Note
Doc Text:
To remove a storage domain it is necessary to first ensure that all disks on the storage domain are moved or removed. This includes any disk(s) that are associated with a template. To manually move or remove disk(s) associated with a template: * Open the "Templates" tab in the Administration Portal. * Select the template from the list. * Click the "Storage" sub-tab. The disks associated with the template will be displayed. Select each one and click the button associated with the desired action.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-26 01:52:44 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)

  None (edit)
Description Haim 2012-05-21 17:39:33 EDT
Description of problem:

I hit some kind of a "deadlock" case: 

- had a domain with x vms and x templates
- wanted to deprecate this domain, create new domain under same pool, 
moved all vms to it, and copied all templates
- when I tried to detach storage domain, was alerted that I cannot detach storage domain while there are vms\templates on it.

problem: i'm stuck with this domain 

- remove template will remove the template object and i won't be able to use it

no need for logs - its a known can_do_action
Comment 1 Haim 2012-05-22 14:08:22 EDT
I don't think this issue is relevant on 3.1 version, as templates table was merged into vms table, also, using floating\shared disks, and all the disks new abstraction layer, along with live storage migration.
Comment 2 Andrew Cathrow 2012-06-04 12:18:20 EDT
Haim, if this isn't relevant on 3.1 I'd like to close it, can you confirm?

thanks
Comment 3 Haim 2012-06-04 13:39:48 EDT
(In reply to comment #2)
> Haim, if this isn't relevant on 3.1 I'd like to close it, can you confirm?
> 
> thanks

will have to confirm (don't think though).
Comment 5 Andrew Cathrow 2012-06-13 08:22:11 EDT
set 3.1 ? flag but not setting ack until the test has been done on 3.1
Comment 10 Daniel Erez 2012-07-23 02:48:17 EDT
Removal of a template disk from a specific storage domain is available through:
Templates main-tab -> Storage sub-tab.
(the current limitation is that each template disk must reside at least on one storage domain; i.e. the last 'copy' of a template disk can't be removed).
Comment 11 Ayal Baron 2012-07-24 16:01:36 EDT
(In reply to comment #10)
> Removal of a template disk from a specific storage domain is available
> through:
> Templates main-tab -> Storage sub-tab.
> (the current limitation is that each template disk must reside at least on
> one storage domain; i.e. the last 'copy' of a template disk can't be
> removed).

But it's *not* the last copy, so why would we prevent removal of the domain?
In addition, even if it is the last copy, we should prevent it iff the template VM has additional disks on other storage domains (otherwise we are removing the entire template + derived VMs, so it shouldn't matter).
Comment 12 Ayal Baron 2012-07-25 04:01:52 EDT
After discussing with Daniel the only solution we came up with here is to add instructions in the error message on where to go in order to remove the copies.
Acking only for this.
Comment 13 Ayal Baron 2012-09-19 07:59:28 EDT
After reviewing the code, even adding such a message is more complex.
Need to add a doc text and solving this within the system will be delayed to a future version.
Comment 15 Stephen Gordon 2012-11-01 15:08:42 EDT
Ayal can you please review the technical note for correctness. I am still confused by the remarks in comment # 10 and comment # 12. 

When can't the disk be deleted? Are we saying that you can end up stuck with a disk forever?
Comment 16 Ayal Baron 2012-11-05 18:10:17 EST
(In reply to comment #15)
> Ayal can you please review the technical note for correctness. I am still
> confused by the remarks in comment # 10 and comment # 12. 
> 
> When can't the disk be deleted? Are we saying that you can end up stuck with
> a disk forever?

No one said anything about disks that cannot be removed.
The issue is that you cannot remove a *storage domain* as long as it contains VMs and disks associated with templates.
To delete the copies of the disks associated with templates without deleting the entire template you need to do what is written in the doc text.
Comment 17 Stephen Gordon 2012-11-05 19:19:07 EST
(In reply to comment #16)
> (In reply to comment #15)
> > Ayal can you please review the technical note for correctness. I am still
> > confused by the remarks in comment # 10 and comment # 12. 
> > 
> > When can't the disk be deleted? Are we saying that you can end up stuck with
> > a disk forever?
> 
> No one said anything about disks that cannot be removed.

comment # 10:

"(the current limitation is that each template disk must reside at least on one storage domain; i.e. the last 'copy' of a template disk can't be removed)."
Comment 18 Ayal Baron 2012-11-06 07:51:55 EST
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > Ayal can you please review the technical note for correctness. I am still
> > > confused by the remarks in comment # 10 and comment # 12. 
> > > 
> > > When can't the disk be deleted? Are we saying that you can end up stuck with
> > > a disk forever?
> > 
> > No one said anything about disks that cannot be removed.
> 
> comment # 10:
> 
> "(the current limitation is that each template disk must reside at least on
> one storage domain; i.e. the last 'copy' of a template disk can't be
> removed)."

Ah, that needs to be revised a bit since you can delete the template and that would delete the disk.
The "limitation" is that if you have a template with multiple disks you cannot completely remove only 1 disks, but this has always been this way (and basically it makes sense).

The thing about templates is that you can have multiple copies of individual disks.  e.g. template T1 has disks d1 and d2 on storage domains sd1 and sd2 respectively.  You can copy d1 to sd2 and have 2 copies of d1 and 1 copy of d2.
You can then delete either d1 from sd1 or d1 from sd2 but not both.
You can also delete the template which would delete d1 and d2 from all domains.

The bug is about removing a *storage domain* not a template and not a disk.
To do this, all the disks which are part of templates have to have copies on other storage domains.

Does this make sense?
Comment 19 Ayal Baron 2012-12-19 06:03:04 EST
Haim, is this still relevant?
Comment 20 Dafna Ron 2012-12-23 09:18:58 EST
(In reply to comment #19)
> Haim, is this still relevant?

no.

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