However, it could very well be that IPMI hardware modules are slow
enough at processing requests that this could pose a problem. What
hardware has this happened on? Was ACPI disabled on boot in the host OS
(it should be; see below)?
snip
The time window for (c) increases significantly (5+ seconds) if the
cluster nodes are enabling ACPI power events on boot. This is one of
the reasons why booting with acpi=off is required when using IPMI, iLO,
or other integrated power management solutions.
If booting with acpi=off, does the problem persist?
Lon - is the requirement for disabling acpi when using integrated fence
devices documented anywhere?
I have searched far and wide on the nature of acpi=off (if it is good or
bad, recommended by Red Hat or anyone out there). Yours is the strongest
against acpi enabled I have found, but not for reasons I would have
expected.
My impression of acpi=off is it borders on a magical cure-all for
boot/installation problems (in part due to bad acpi by server/firmware
vendors), but that it also acts as some kind of safe mode (e.g. ht is
disabled, does things to IRQ routing, etc) which may have an adverse
effect on system performance.
Are you aware of any negative effects, performance or otherwise, which
acpi=off will cause. E.g. if the only adverse effect of acpi=off is
hyperthreading being disabled, users that want it back, can so using acpi=ht
Riaan
note: IMHO, a Knowledge Base article on the use of acpi=off (and its
variants), for general RHEL installations, and pertaining to RHCS/GFS
implementations would be very welcome.
begin:vcard
fn:Riaan van Niekerk
n:van Niekerk;Riaan
org:Obsidian Systems;Obsidian Red Hat Consulting
email;internet:riaan@xxxxxxxxxxxxxx
title:Systems Architect
tel;work:+27 11 792 6500
tel;fax:+27 11 792 6522
tel;cell:+27 82 921 8768
x-mozilla-html:FALSE
url:http://www.obsidian.co.za
version:2.1
end:vcard
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
