Bug 1124318 - Can define a VM POOL as HA
Summary: Can define a VM POOL as HA
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.6.0
Assignee: Shahar Havivi
QA Contact: sefi litmanovich
Whiteboard: virt
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-29 08:41 UTC by Eli Mesika
Modified: 2016-02-10 19:49 UTC (History)
10 users (show)

Fixed In Version: ovirt-engine-3.6.0-0.0.master.20150412172306.git55ba764
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-04 11:23:55 UTC
oVirt Team: Virt

Attachments (Terms of Use)
screenshot (55.85 KB, image/png)
2014-07-29 08:42 UTC, Eli Mesika
no flags Details

System ID Priority Status Summary Last Updated
oVirt gerrit 35071 master MERGED UI: migration down time shouldn't be enabled by default. Never

Description Eli Mesika 2014-07-29 08:41:24 UTC
Description of problem:
Migration options must be filled when marking POOL VM as HA

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

How reproducible:

Steps to Reproduce:
1.Create a new VM POOL with 1 VM
2.Edit the created VM 
3.Mark the VM as HA 
4.Try to save

Actual results:
The Host TAB is marked with RED and when you open it it marks the Migration Options field with RED (see attached images)

Expected results:
Should work and save HA setting as is done for VM that is not in pool

Additional info:
Setting HA for a VM that is not in a POOL works fine

Comment 1 Eli Mesika 2014-07-29 08:42:04 UTC
Created attachment 922067 [details]

Comment 2 Eli Mesika 2014-07-29 08:52:12 UTC
Changing the subject since a POOL VM should not be set to HA at all.
So the problem is that if we edit the POOL VM after POOL creating, we have the ability to select the HA TAB for that VM

Comment 3 sefi litmanovich 2015-07-23 11:32:50 UTC
It is not very clear from this bug what was the decided solution for this problem.. I tried some flows, please let me know if this is the expected behaviour and we should re open or open a new one:

1. In all cases there's no ability to create/edit a vmPool as HA.
2. In a specific VM in the pool you can change to HA regardless to Migration Options.

This seems as expected.

As for the 'Use Custom migration downtime' option, behaviour is a bit strange I think:

1. Create VMpool without defining 'Use Custom migration downtime': this result in vm inheriting this configuration. If you edit the VM and mark this checkbox, the value box is still gray so you can not define a value, and after confirming no error or red mark appears but if you edit VM again you see checkbox unmarked.

2. Create VMpool and define 'Use Custom migration downtime' + some value x: this result in vm inheriting this configuration. If you edit the VM the checkbox is marked and the value from pool is there. If you uncheck the box and confirm, next time you edit the VM the behaviour is similar to (1) - meaning you cannot re-check the box.

I wonder if this is the wanted logic behind this configuration or maybe it's a GUI bug.. please let me know what you think.

Comment 4 sefi litmanovich 2015-07-23 11:33:31 UTC
I forgot to mention in previous comment, this was tested with ovirt-engine-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch.

Comment 5 Shahar Havivi 2015-07-23 11:40:06 UTC
Sefi this is not related to HL VMs as the bug state,
This is a validation error as you can see in the attached screenshot that Eli posted.
"Use custom migration downtime" field not meant to be changeable in Pool and the patch set it to unchangeable.

Comment 6 sefi litmanovich 2015-08-04 08:09:28 UTC
Verified with 3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch according to flow specified on comment 3 and shahar's comment 5.
Please advise whether another bz should be opened regarding the 'Use Custom migration downtime' behaviour also mentioned on comment 3.

Comment 7 Eli Mesika 2015-08-04 10:01:07 UTC
(In reply to sefi litmanovich from comment #6)
Yes, I suppose a different one for the he 'Use Custom migration downtime' behavior

Comment 8 Sandro Bonazzola 2015-11-04 11:23:55 UTC
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.

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