Bug 1033215 - RHEV 3.2 hypervisor power management options continue to be used after deletion
Summary: RHEV 3.2 hypervisor power management options continue to be used after deletion
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.0
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: ---
: 3.4.0
Assignee: Eli Mesika
QA Contact:
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-21 17:44 UTC by Robert McSwain
Modified: 2018-12-05 16:40 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-29 17:00:56 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)

Description Robert McSwain 2013-11-21 17:44:35 UTC
Description of problem:
RHEV 3.2 hypervisor power management options continue to be used after deletion

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

How reproducible:
Every time

Steps to Reproduce:
1. Configure power management on a hypervisor and set additional options (valid or not). 

2. Using a fencing agent with debug enabled on the hypervisors log what options are supplied to it by VDSM. 
See https://access.redhat.com/site/node/386203/draft for more explicit testing of and a workaround for this.

3. In the RHEV-M GUI, test the power management.

4. Delete/unconfigure those options in RHEV-M and test again

Actual Results:
The deleted options are sent to the fencing agent.

Expected Results:
The current options are sent to the fencing agent and the vdc_options in the database should be updated instead of using outdated values.

Comment 1 Eli Mesika 2013-12-04 14:39:56 UTC
Please attach engine + vdsm logs

Comment 2 Eli Mesika 2013-12-04 14:48:48 UTC
In my test, each time I had changed a parameter, the changed value had been sent.

Also , I found a problem in apc_snmp agent which bypass authentication and do the operation (even rebbot) without authenticating first.

I has sent a separate message to marek G who is the fence-agents maintainer and I think that maybe here the apc_snmp was used and the user/password field were changed

Comment 3 Marek Grac 2013-12-11 09:40:13 UTC
For apc_snmp (and a lot of other older SNMP systems) the only authetication is usually done only via community name and login/pass is ignored. This can be configured on some later models.

Comment 4 Eli Mesika 2013-12-11 09:54:07 UTC
1) engine + vdsm logs please
2) screenshots of the changed values before clicking the TEST button

Comment 5 Robert McSwain 2013-12-24 16:08:07 UTC
I have requested this information from the individual who wanted the bug opened and will let you know as soon as I hear from them. Thank you!

Comment 6 Robert McSwain 2014-01-07 15:04:51 UTC
The individual in this case is going to retest on 3.3 RC and see if the issue persists. If so then we'll provide logs there, otherwise we'll get logs from a previous case from 3.2 and provide those. Thanks!


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