Bug 827051 - webadmin: deactivate disk is disabled for IDE interface
webadmin: deactivate disk is disabled for IDE interface
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.0
x86_64 Unspecified
high Severity high
: ---
: 3.1.0
Assigned To: Tomas Jelinek
Dafna Ron
storage
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-31 10:15 EDT by Dafna Ron
Modified: 2016-02-10 12:15 EST (History)
8 users (show)

See Also:
Fixed In Version: SI6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 15:07:36 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 Dafna Ron 2012-05-31 10:15:11 EDT
Description of problem:

deactivate button in virtual disks sub tab (under vm's) is greyed out for IDE drives. 
this should not be greyed out - only hot plug of IDE is not supported. 

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

si4

How reproducible:

100%

Steps to Reproduce:
1. create an IDE disk and try to detach it
2.
3.
  
Actual results:

button is greyed out 

Expected results:

we should be ablet to deactivate the drive as long as the vm is down. 

Additional info:
Comment 1 Tomas Jelinek 2012-06-12 03:38:18 EDT
It works like this (considering the VM is down):
- create a new IDE disk
- the disk gets in LOCKED state => can not be deactivated yet (button grayed out)
- after a while, it gets to OK state => can be deactivated (button is available)

@Dafna: if you wait a while, is the deactivate button still grayed out? If not, it should mean that something went wrong and the disk stayed in LOCKED state. Could you please have a look at the engine/vdsm logs if there are some exceptions?
Comment 2 Dafna Ron 2012-06-12 04:50:56 EDT
this is not an image status or refresh issue.
I spoke to Daniel and this was done on propose since kvm will not support hot-plug for IDE disks.
since this is not hot plug but a simple db update operation while the vm is down there should be no problem allowing this while the vm is down.
Comment 3 Tomas Jelinek 2012-06-12 05:47:49 EDT
Just to be sure:

This is how it works for you:
- add a new disk
- first the deactivate button is grayed out (as it is in LOCKED state)
- after a while, the button gets available (as the disk is in OK state)

The intended behavior is:
- add a new disk
- the deactivate button gets immediately available (ignoring if it is locked or not)

Do I understand it well?
Comment 4 Dafna Ron 2012-06-12 07:14:24 EDT
no. It is correct to lock the deactivate button while the vm is in image locked

you have two interface disk types: IDE and VirtIo.
when you create IDE disk the deactivate button will always remain greyed out (even after the disk status is OK and not Locked).

do the following:
1) create a new vm -> create a disk with interface type IDE 
2) once the disk is created and status is no longer on image lock the deactivate tab will still not be available.

the reason for that is that it was grayed out intentionally by the UI team because kvm does not support hot plug for IDE interface.
Comment 5 Tomas Jelinek 2012-06-12 09:55:27 EDT
Now I understand the source of confusion. You are talking about the si4, where the behavior was indeed that for the IDE interface the deactivate button is always grayed out. 
I'm looking at the current head of oVirt which contains the fix (git: 28b3bd7516eba85ad6b4737bba5a733db50de1ee) which changes the behavior like I have described in my previous comment:
- add a new disk
- first the deactivate button is grayed out (as it is in LOCKED state)
- after a while, the button gets available (as the disk is in OK state)
Comment 7 Tomas Jelinek 2012-06-12 11:10:04 EDT
already fixed in upstream,
git: 28b3bd7516eba85ad6b4737bba5a733db50de1ee
Comment 9 Haim 2012-06-12 14:52:42 EDT
(In reply to comment #7)
> already fixed in upstream,
> git: 28b3bd7516eba85ad6b4737bba5a733db50de1ee

Tomas, setting bug in modified, please state the official version where bug is fixed.
Comment 10 Einav Cohen 2012-06-13 04:49:12 EDT
(In reply to comment #9)
> (In reply to comment #7)
> > already fixed in upstream,
> > git: 28b3bd7516eba85ad6b4737bba5a733db50de1ee
> 
> Tomas, setting bug in modified, please state the official version where bug
> is fixed.

- Moving bug to POST, as downstream bugs that their fix was merged in upstream repo (but not in downstream repo) shouldn't move to MODIFIED.
- Shouldn't official version be filled when BZ moves to ON_QA?
Comment 11 Dafna Ron 2012-06-19 04:24:38 EDT
verified on si6

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