Red Hat Bugzilla – Bug 853227
rhevm trys to run power management command on host during its installation
Last modified: 2016-02-10 14:43:50 EST
Version: rhevm-3.1.0-14.el6ev.noarch Scenario: I've installed few hosts using a rhevm-sdk based script that triggers their installation and configure power management right after installaiton starts. I found in the log that rhevm failed to run a power management command for each of my installed hosts, rhevm tried to run that command during the installation of the hosts. Reproduction steps: 1. Install a host or few hosts in parallel 2. Configure the host's power management during its installation using rhevm-sdk From engine.log: 2012-08-30 22:13:34,780 INFO [org.ovirt.engine.core.bll.UpdateVdsCommand] (ajp-/127.0.0.1:8009-7) [1ec2b6da] Running command: UpdateVdsCommand internal: false. Entities affected : ID: 8eb698e6-f2e7-11e1-9ad2-03637d3562a9 Type: VDS 2012-08-30 22:13:35,180 ERROR [org.ovirt.engine.core.bll.FencingExecutor] (ajp-/127.0.0.1:8009-7) [1ec2b6da] Failed to run Power Management command on Host puma19, no running proxy Host was found.
are we sure this isn't just trying to validate the PM configuration? log is missing which power management command was sent.
I assume that it is the command that validates the PM configuration, it just need to be running only after host is up and running or PM configuration should not be allowed during host installation - the first option is the preferred one. I don't have a log of the PM command, but anyway I use the following code for PM configuration using rhevm-sdk: host_obj = self.getSdkProxy().hosts.get(self.getName()) host_obj.power_management=params.PowerManagement(address='.'.join([self.getName() + c.PM_ADDRESS_ADDITION, self.getDomain()]), username=pm_user, password=pm_passwd, enabled='true', type_=pm_type) host_obj.update()
eli - thoughts?
(In reply to Itamar Heim from comment #4) > eli - thoughts? When a Host is saved and have PM configured, the configuration is tested by sending a "status" command to the PM agent. In this case there is no Host in the Cluster or DC that can serve as a proxy and therefor the generated errors are OK and working as desgned. Since that we are retring to find a proxy before giving up FindFenceProxyRetries times (3 by default) with delay of FindFenceProxyDelayBetweenRetriesInSec (30 sec by default) this mean that we didn't find a proxy for 90 sec before giving up. I assume that with the new 3.3 Install procedure that don't require a Host reboot we will get those Hosts up withing those 90 sec and get a proxy as well, so I don't expect this BZ to be reproduced in 3.3
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.