Bug 1455502 - RHV 4.x still need lanplus=1 for power management
Summary: RHV 4.x still need lanplus=1 for power management
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Eli Mesika
QA Contact: Petr Matyáš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-25 11:02 UTC by Jaroslav Spanko
Modified: 2020-09-10 10:37 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-08 07:29:26 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1478354 0 medium CLOSED [Docs][Tech][Admin] Add suggestion to use specific power management agent instead of common ipmilan 2021-02-22 00:41:40 UTC

Internal Links: 1478354

Description Jaroslav Spanko 2017-05-25 11:02:28 UTC
Description of problem:

ipmilan still need lanplus=1 in the Power Management option box, if not it fails with 
Unable to obtain correct plug status or plug is not available

Version-Release number of selected component (if applicable):
RHV 4.x

How reproducible:
100%

Steps to Reproduce:
1. use ipmilan 
2. without setting test fails
3. add the lanplus=1 and test works OK

Actual results:
Unable to obtain correct plug status or plug is not available

Expected results:
Test OK

Additional info:
This should be fixed in RHEV so the option should not be needed
https://bugzilla.redhat.com/show_bug.cgi?id=1219620

Thank you

Comment 8 Eli Mesika 2017-06-04 14:39:45 UTC
It seems that this can be solved by running 

engine-config -s CustomFenceAgentDefaultParams=ipmilan:lanplus;

However , this throws currently and error , I opened a blocked BZ on that and will resolve it first

Comment 9 Eli Mesika 2017-06-15 14:10:06 UTC
In order to add automatically 'lanplus=1' for all your hosts with ipmilan device m please run the following :

> engine-config -s CustomFenceAgentDefaultParams=ipmilan:lanplus=1;

Please keep in mind that in order that this change will take affect, you must restart your application.

Comment 10 Roman Hodain 2017-06-21 14:39:57 UTC
I do not agree with closing this a not a bug. 

1) Here is snippet of the text from ipmitool man pages:

When an IPMI password is changed on a remote machine with the IPMIv1.5 lan interface the new password is sent across the network as clear text. This could be observed and then used to attack the remote system. It is thus recommended that IPMI password management only be done over IPMIv2.0 lanplus interface or the system interface on the local station.

The output is clear we should use lanplus.

2) How is the RHV admin suppose to know what parameters should be added there? The admin does not know that a tool called ipmitool is used. That is an RHV internal thing.

3) as far as I understand from the bug description RHEV 3 used ipmilan=1 by default and RHV 4 does not. That can be confusing for people upgrading from 3 to 4. It may or may not be understood as regression, but I do not what to discuss this.

4) The most important is that it does not matter if the parameter is there by default or not as long as the user/admin knows that they may need to add/remove the parameter to make the fencing work. There is not way to determine it from the current situation. If we put there at least additional drop down menu for ipmilan which allows a simple change of lanplus and some explanation what it does in the form. It would be nice.

Comment 11 Jaroslav Spanko 2017-06-22 07:13:59 UTC
just my 2 cents why I opened this bug
The fix which mentioned Eli does not match what Martin mentioned in comment #6.
With set the CustomFenceAgentDefaultParams this will be global and it do not consider if the host need need lanplus=1 or not.

I agree that we have lot of hosts which works without lanplus=1, but we have also lot of hosts which does not work. In the last months i had a few cases when cu installed RHV 4, had xy hosts and only for x was need to pass the lanplus=1.

I would say this could be handle better, if we do not want to do the same as for idrac would be great have some option for this. As the some newer servers(G9,G8,G7) customers will hit this situation again.

Thanks

Comment 12 Martin Perina 2017-06-23 20:35:46 UTC
(In reply to Roman Hodain from comment #10)
> I do not agree with closing this a not a bug. 
> 
> 1) Here is snippet of the text from ipmitool man pages:
> 
> When an IPMI password is changed on a remote machine with the IPMIv1.5 lan
> interface the new password is sent across the network as clear text. This
> could be observed and then used to attack the remote system. It is thus
> recommended that IPMI password management only be done over IPMIv2.0 lanplus
> interface or the system interface on the local station.
> 
> The output is clear we should use lanplus.

The main issue is that we don't know how many existing hardware using ipmilan fence agent supports only lanplus=0 and fails with lanplus=1. As I have already mentioned above, we are using lanplus=0 as default from beginning of RHV. Personally I fear changing default to lanplus=1 for ipmilan fence device type, because customers may miss this change and they may find out that their fence device does not work only during some disaster.

But we can go over existing fence device types and we can prove that some fence device types are working only with lanplus=1 (or with both lanplus values), we can change the defaults for it.

> 
> 2) How is the RHV admin suppose to know what parameters should be added
> there? The admin does not know that a tool called ipmitool is used. That is
> an RHV internal thing.

We are not using ipmitool, but we are using corresponding fence_agent_XYZ. If this is not mentioned within documentation, then we should add it, because we don't have any option how to reliably detect type of fence device. So customer needs to find properly working fence agent and test all required options (the only way how to do this is by corresponding fence_agent_XYZ invocation) and afterwards add this fence agent to the host including proper options.

> 
> 3) as far as I understand from the bug description RHEV 3 used ipmilan=1 by
> default and RHV 4 does not. That can be confusing for people upgrading from
> 3 to 4. It may or may not be understood as regression, but I do not what to
> discuss this.

Not true, as I have already mentioned above, ipmilan fence-agent is using lanplus=0 as default from beginning of RHV.

> 
> 4) The most important is that it does not matter if the parameter is there
> by default or not as long as the user/admin knows that they may need to
> add/remove the parameter to make the fencing work. There is not way to
> determine it from the current situation. If we put there at least additional
> drop down menu for ipmilan which allows a simple change of lanplus and some
> explanation what it does in the form. It would be nice.

Unfortunately there's no documentation for fence agents other than man page, so we don't have any way how to provide a link from webadmin. We can only add to the documentation, that customer need to take a look at corresponding man page to find out which options are available.


(In reply to Jaroslav Spanko from comment #11)
> just my 2 cents why I opened this bug
> The fix which mentioned Eli does not match what Martin mentioned in comment
> #6.
> With set the CustomFenceAgentDefaultParams this will be global and it do not
> consider if the host need need lanplus=1 or not.
> 
> I agree that we have lot of hosts which works without lanplus=1, but we have
> also lot of hosts which does not work. In the last months i had a few cases
> when cu installed RHV 4, had xy hosts and only for x was need to pass the
> lanplus=1.
> 
> I would say this could be handle better, if we do not want to do the same as
> for idrac would be great have some option for this. As the some newer
> servers(G9,G8,G7) customers will hit this situation again.
> 

This is what I mentioned above, if we can prove for example that ILO4 works correctly with lanplus=1, then we change the defaults for ILO4. But I'd prefer not to change the default for ipmilan.

Comment 13 Oved Ourfali 2017-06-25 05:36:31 UTC
Petr, can you test ILO4 with lanplus=1?

Comment 14 Lukas Svaty 2017-07-14 07:43:04 UTC
Will need to check with QA dep, if we have such machine available, will reply afterwards.

Comment 15 Petr Matyáš 2017-07-17 09:14:23 UTC
(In reply to Oved Ourfali from comment #13)
> Petr, can you test ILO4 with lanplus=1?

Actually lanplus=1 is the default for fence_ilo4 command.
It works correctly when specifying it explicitly on options line and also when options line is empty.

Comment 20 Martin Perina 2017-07-17 21:10:01 UTC
Apologize for confusion, here's summary for the bug:

In RHV 4.0.z ilo4/ilo4 fence agent type is mapped to ipmilan, but inside engine lanplus=1 is is defined as default option.

In RHV 4.1.0 we have changed internal mapping of ilo3 and ilo4 fence agents from fence_ipmilan to native agent implementation fence_ilo3/fence_ilo4 (BZ1126753). By default internally lanplus option is enabled on both fence_ilo3/fence_ilo4, so no need to specify that option within engine. This means that all new HP servers which contains either iLO3 or iLO4 support should be configured with ilo3/ilo4 fence agent instead of generic ipmilan and lanplus will be used by default.

For Dell servers which supports DRAC7, drac7 fence agent type should be used. It's internally inside engine mapped to fence_ipmilan, but inside engine we define lanplus=1 as a default for drac7 fence agent type.

The recommendation is to use specific fence agent type like ilo4 or drac7 instead of generic ipmilan. As I've stated above, changing defaults for ipmilan is dangerous, because this change may not be noticed and it may broke already configured fence agents.

Jaroslav, could you please check that using ilo4/drac7 instead of ipmilan solved the issue in your setup? If so, we can close the bug as NOTABUG.

Comment 21 Martin Perina 2017-08-01 20:50:10 UTC
Jaroslav, any updates?

Comment 22 Jaroslav Spanko 2017-08-04 10:26:09 UTC
Hi Martin

This make sense, i was able to test this and it works.
Is what you wrote documented somewhere ? Would be good to have this in documentation/KCS
As is not mentioned in

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/technical_reference/fencing

Before closing, can i create bug to add this to documentation or KCS is enough from your point of view ? 

Thanks for this

Comment 23 Martin Perina 2017-08-04 12:17:50 UTC
(In reply to Jaroslav Spanko from comment #22)
> Hi Martin
> 
> This make sense, i was able to test this and it works.
> Is what you wrote documented somewhere ? Would be good to have this in
> documentation/KCS
> As is not mentioned in
> 
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/
> html/technical_reference/fencing
> 
> Before closing, can i create bug to add this to documentation or KCS is
> enough from your point of view ? 
> 
> Thanks for this

I've just created BZ1478354 to cover this, feel free to add more info into BZ1478354 if needed.

Thanks

Comment 24 Jaroslav Spanko 2017-08-08 07:03:15 UTC
Hi Martin 
I total forgot to ask one question:
We spoke only about the HP and the Dell servers, but what about Super-micro based server or other which use IPMI?
As the IPMI is using the ipmilan this will face the same issue with lanplus=1. 
I understand that changing defaults for ipmilan is dangerous, do you have any idea/comments for this one ? 
Thanks !

Comment 25 Martin Perina 2017-08-08 07:29:26 UTC
(In reply to Jaroslav Spanko from comment #24)
> Hi Martin 
> I total forgot to ask one question:
> We spoke only about the HP and the Dell servers, but what about Super-micro
> based server or other which use IPMI?
> As the IPMI is using the ipmilan this will face the same issue with
> lanplus=1. 
> I understand that changing defaults for ipmilan is dangerous, do you have
> any idea/comments for this one ? 
> Thanks !

Do such servers have specialized fence agent (like fence_ilo4 for HP)? If not, then they have to live fence_ipmilan. If so and it's not listed in supported fence agents for RHV, then please file new RFE to include them. Otherwise they will have to live with ipmilan and as I noted above we don't want to change defaults for ipmilan


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