30 jul 2012 = =3D kl. 11.01 skrev Itamar Heim:

<=3D blockquote type=3D3D"cite">

On 07/30/2012 08:56 AM, Karli Sj=3DF6berg w= rote=3D :

2=3D 8 jul 2012 kl. 14.11 skrev Moti Asayag:

On 07/26/2012 02:53 PM, Karli Sj=3DF6berg wrote:
Hi,

=
<=3D blockquote type=3D3D"cite">In my DC, I have three hosts added:

<=3D blockquote type=3D3D"cite">
hostA
hostB
=3D
hostC

<=3D blockquote type=3D3D"cite">
I want a way to forc= e on=3D ly to use hostA as a proxy for power commands.

<= /blo=3D ckquote>
Th=3D e algorithm of selection a host to act as a proxy for PM commands is
=3D quite naive: any host from the system with status UP.

You = can =3D see how it is being selected in FencingExecutor.FindVdsToFence()
= from=3D
ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/eng= =3D ine/core/bll/FencingExecutor.java

<= bloc=3D kquote type=3D3D"cite">
There is no other algori= thm =3D for the selection at the moment.

How would you handle a ca= se i=3D n which hostA isn't responsive ? Wouldn't
you prefer trying to pe= rfor=3D m the fencing using other available host ?

<= /blo=3D ckquote>
Let me explain a little to make you bet= te=3D r understand my reasoning
behin= d =3D this configuration.

We work with segmented, separated networks.= O=3D ne network for public
access, o= ne=3D for storage traffic, one for management and so on. That
means that if the nodes themselves have to do the= ir=3D own
power-management, the node= s =3D would require three interfaces each, and the
metal we are using for hosts just don=3DB4t have that. But if= we =3D can use the
engine to do that, = th=3D e hosts would only require two interfaces, which
most 1U servers are equipped with as standard (plus one=3D
iLO/IPMI/whatev), so we can use th= em=3D as hosts without issue. Then the
backend has one extra interface that it can use to communicate over the
power management network to the r= es=3D pective service processor with.
<=3D br>
Is there a "better" way to achi= ev=3D e what we are aiming for? Ideally, I
would like to set up the two NICs in a bond and create VLAN-interfaces<= =3D br>
on top of that bond. That way, = I =3D can have as many virtual interfaces as
I want without having more than two physical NICs, but I haven=3DB4t = be=3D en
able to find a good HOWTO ex= pl=3D aining the process.

I think there is a difference between:
1. allowing engine to fen= =3D ce
2. allowing to choose fencing host per cluster (or per host)

i= =3D t sounds like you actually want #1, but can live with #2, by installing the engine as a host as well.