Bug 1033215

Summary: RHEV 3.2 hypervisor power management options continue to be used after deletion
Product: Red Hat Enterprise Virtualization Manager Reporter: Robert McSwain <rmcswain>
Component: ovirt-engineAssignee: Eli Mesika <emesika>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: high Docs Contact:
Priority: urgent    
Version: 3.4.0CC: acathrow, dsulliva, emesika, iheim, lpeer, mgrac, pstehlik, Rhev-m-bugs, rmcswain, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.4.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-29 17:00:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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!