[Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple Agent Support

Lon Hohberger lhh at redhat.com
Fri Nov 16 17:42:12 UTC 2012


On 11/16/2012 11:35 AM, Itamar Heim wrote:
> On 11/16/2012 03:06 AM, Eli Mesika wrote:
>>
>> Requirements: http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents
>> DR          :
>> http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> Lon - thoughts on this?
> 


Looks the first thing that jumps out is that it looks like you can have:

   - do this one off action && do this one off action
   - do this one off action || do this one off action

So, try device A, and if this fails, try device B - or, if it's really
two ports on device A (but two calls), both must succeed.

One thing I wonder is whether these use cases are covered.

1) With WTI units and similar, many have two independent power rails.
This means that if someone trips over one of the power cables going to
the power switch unit, the host will still have power.

   A || (B && B')
   ^     ^    ^
   |     +----+---- WTI dual-rail remote power switch
   |                (two ports used - one on each power rail)
   |
   +--------------- iLO / IPMI / etc.

2) More common with the smaller APC units is that most have a single
power supply rail.  For power redundancy, it's not recommended to ever
plug both power supplies in to the same single-rail APC unit.

   A || (B && C)
   ^     ^    ^
   |     |    +---- APC device 2 port 1
   |     +--------- APC device 1 port 1
   +--------------- iLO / IPMI / etc.

E.g. try the iLO device first, but if that fails, you need to cut off
both power supplies (then on).  This is presumably less harsh to the
machines.  I also would not /necessarily/ limit things to two power
supplies, but I think two power supplies is the 99% use case.

I'll keep looking.

-- Lon



More information about the Devel mailing list