Quiet a Homelab Server: iDRAC and iLO Fan Control

The loudest thing in most homelabs is a rackmount server running its fans off a datacenter fan curve. A used Dell R730 idles fine on paper and screams in practice, because enterprise chassis ship with cooling tuned for a 35 degrees C aisle and the static pressure of a packed 1U or 2U, not a spare room. A machine drawing 200 watts at idle can still push its fans hard enough to be heard through a closed door.

This guide covers the two levers that matter: fan control, to make the box quiet, and power tuning, to cut what it costs to run. They are separate problems with separate fixes. Fan control also splits hard by vendor and generation, so this is honest about where it works and where it does not: full manual iDRAC fan control on the Dell iDRAC7 and iDRAC8 generation, a firmware wall on modern iDRAC9, and no supported control at all on HP iLO. The commands below were verified in July 2026 against Dell’s and HPE’s own documentation and the most-used community fan controllers; the watt and decibel figures are cited to published measurements, not benchmarked here.

Why enterprise servers scream in a spare room

A server’s baseboard management controller (Dell iDRAC, HP iLO) runs the fans off a thermal algorithm that reads inlet, exhaust, and per-component temperatures and then applies a conservative minimum floor. That floor was chosen for a data center: high inlet temperatures, dense racks, and a service contract that treats a cooked component as a five-figure problem. In a home, the inlet air is cooler and the box is nearly idle, so that same floor is simply louder than it needs to be.

There is a second, sharper cause. When the controller sees a PCIe card it does not recognize, a crossflashed HBA, a cheap 10GbE NIC, an NVMe add-in card, it has no temperature telemetry for that card, so it ramps every fan to a fixed elevated speed as a blind safety measure. This is why a homelab server that was quiet as shipped starts roaring the moment you add the exact parts a homelab needs. Both problems are fixable, but only on hardware that lets you reach the fan controller at all.

Which servers you can actually quiet

Before touching a command, know what your platform allows. The gap between a Dell iDRAC8 box and an HP iLO4 box is the difference between a two-minute fix and flashing unofficial firmware.

The short version: a Dell of the R730 era is the platform to buy if a quiet server is the goal. The rest of this guide leads with that path, then covers the modern-Dell wall and the HP reality honestly.

Dell iDRAC fan control with ipmitool

On iDRAC6, iDRAC7, and iDRAC8 (PowerEdge 11th to 13th generation, so the R610, R710, R620, R720, R630, and R730), fan speed is set with three undocumented Dell OEM IPMI commands. They are not supported by Dell and can be removed by a firmware update, but on this generation they work and they are the whole trick. Install ipmitool first. On Proxmox VE or any Debian host:

sudo apt install ipmitool

On a Rocky or RHEL host the package is the same name under dnf:

sudo dnf install ipmitool

Run the commands locally, on the server’s own operating system, and ipmitool talks to the BMC through the in-band interface with no credentials. First switch the fan controller out of automatic mode into manual:

ipmitool raw 0x30 0x30 0x01 0x00

The final byte is the mode: 0x00 is manual, 0x01 is automatic. With manual mode set, the next command fixes the speed. The 0xff means “all fans” and the last byte is the duty cycle as a percentage written in hexadecimal:

ipmitool raw 0x30 0x30 0x02 0xff 0x1e

That sets every fan to 30 percent (0x1e). The mapping is simply the percentage converted to hex, which is why 20 percent is 0x14 and 50 percent is 0x32. The common values:

Start at 30 percent, not 10. A 2U dual-socket box under any real load needs more airflow than a bare idle bench test suggests, and the difference between quiet and safe is a few percent, not a shutdown. Drop it in steps and watch the temperatures (covered below) before settling lower.

One command hands cooling back to the server at any time, and it is the one to remember:

ipmitool raw 0x30 0x30 0x01 0x01

If you manage the box over the network instead of from its own shell, add the lanplus transport and the iDRAC address and credentials, and enable IPMI over LAN first under iDRAC Settings, Connectivity, IPMI Settings. The remote form of the manual-mode command, with a real iDRAC IP substituted for the example, is:

ipmitool -I lanplus -H 10.0.1.50 -U root -P your-idrac-password raw 0x30 0x30 0x01 0x00

Swap the example address, user, and password for your own iDRAC values. Every command in this section behaves the same over the network as it does locally.

Stop the third-party PCIe card fan ramp

If the fans stay high even after you set a low manual speed, the culprit is almost always the third-party PCIe cooling response. The card that triggers it is usually the one every ZFS build adds: a Dell PERC H310 crossflashed to LSI 9211-8i IT-mode so the disks pass straight through, or an inexpensive 10GbE card like a Mellanox ConnectX-3. iDRAC cannot read a temperature from those cards, so it applies a fixed elevated fan floor. If you are still choosing the network card, the trade-offs between these older cards and current ones are covered in the 10GbE NIC guide.

Dell documents the fix for 13th-generation servers (the R230 through R930, including the R730) in a support article. One command disables the blind PCIe ramp while leaving the normal temperature-driven cooling intact:

ipmitool raw 0x30 0xce 0x00 0x16 0x05 0x00 0x00 0x00 0x05 0x00 0x01 0x00 0x00

The command is safe in the sense Dell describes: it removes only the fan response tied to an unrecognized card, not the real thermal algorithm. To put the ramp back, the eleventh byte changes from 0x01 to 0x00:

ipmitool raw 0x30 0xce 0x00 0x16 0x05 0x00 0x00 0x00 0x05 0x00 0x00 0x00 0x00

The command set is documented by Dell for 13th-gen hardware and is community-tested on the 12th-gen iDRAC7 boxes (the R720 and siblings) as well, though Dell scopes the support article to 13G. Full detail is in Dell KB 000135682.

Make the setting stick without cooking the server

Manual fan mode is transient. It does not reliably survive a reboot, an iDRAC reset, or a cold power-cycle; the controller reverts to Dell’s automatic algorithm. Do not treat that as a bug to fight. Reapplying a fixed low speed blindly on every boot is how a server ends up throttling or shutting down after a workload changes.

The correct pattern is a small service that does two jobs: it reapplies your fan profile after boot, and it continuously polls temperatures and hands control back to the BIOS the moment a CPU crosses a safe threshold. Rather than hand-roll that, run a maintained controller that already implements the watchdog logic. The widely used tigerblue77 iDRAC fan controller runs as a container and reverts to Dell’s automatic curve whenever the CPU temperature exceeds a configurable ceiling; a systemd port of the same logic exists for hosts that do not run Docker. This is the part that turns a party trick into something safe to leave running on the Proxmox host you built.

The modern-Dell caveat lives here too. On 14th-generation iDRAC9 (the R640 and R740), Dell removed this capability. The last firmware that honored the fan commands is iDRAC9 3.30.30.30; from 3.34.34.34 onward the command returns an “Insufficient privilege level” error and does nothing, and Dell has stated the change is permanent. An R740 on current firmware does not tune down to 20 percent the way an R730 does. What remains on modern iDRAC9 is the third-party PCIe ramp disable above and Dell’s fan-offset and racadm thermal settings, which nudge the curve but do not give arbitrary static control. If a silent box is the priority, that is a strong reason to buy the R730-era Dell over the newer one when choosing the server itself.

HP iLO: the honest options

HP is where this gets uncomfortable. iLO4, the management controller on Gen8 and Gen9 boxes like the DL380 Gen9, exposes no supported way to set a fan speed. You can view thermal data and pick a thermal profile; you cannot tell the fans to run at 30 percent. The entire ecosystem of community fan-control projects exists precisely because that lever does not ship.

Those projects work by flashing patched iLO4 firmware that re-enables factory debug utilities HP hides in production builds. The reference toolkit, kendallgoto/ilo4_unlock, unlocks an SSH fan command, so you can log into the iLO over SSH and run something like fan p 4 max 90 to cap a fan on a 0 to 255 scale. It is real and it works, on Gen8 and Gen9 only, with iLO4 firmware up to version 2.77 (2.78 and 2.79 had the utilities stripped). It is also genuinely dangerous. The project’s own README states that a flashing error can permanently brick the iLO, that its flash chip cannot be reprogrammed to recover, that there is no warranty, and that misusing the fan controls can overheat the server. Flashing it also voids HP support. This is not a casual tweak; it is a modification for someone who can physically recover the machine, or recover it headless with an IP-KVM, and accepts the brick risk.

Gen10 and iLO5 are locked tighter, not looser. No community mod exists for them, and iLO5 only offers a configurable minimum fan speed, which raises the floor but never forces the fans below what the thermal algorithm wants. The one supported HP lever is in the BIOS: under RBSU, Fan and Thermal Options, the Thermal Configuration setting offers Optimal Cooling, Enhanced CPU Cooling, Increased Cooling, and Maximum Cooling. Optimal Cooling is already the default and is the quietest of the four, so this setting is mostly useful for confirming you have not accidentally selected a louder mode. It is not a fan-curve editor. The honest conclusion for HP: on Gen9 you either accept the noise, take the firmware-mod risk, or put the box somewhere its noise does not matter. For a quiet homelab bought new to you, a Dell of the same era is the easier platform.

Cut the idle power draw on Proxmox

Noise and power are separate levers, and the power one saves real money on a machine that runs 24/7. At the US average residential rate of about 18.83 cents per kWh, one watt drawn continuously for a year costs roughly 1.65 dollars. On a dual-socket server that idles in the low hundreds of watts, trimming the idle draw is worth tens of dollars a year before the box does any work.

Measured idle figures vary widely with CPU count, memory, and drives, so treat published numbers as configuration-specific rather than universal. One R730 with dual 18-core E5-2699 v3 CPUs idled around 321 to 336 watts, dropping to roughly 196 to 210 watts once powerd++ let the operating system govern power states, a cut of about a third. A DL380 Gen9 review measured about 90 watts idle with dual E5-2695 v3 CPUs and 39 watts with a single E5-2620 v4. The lesson is not a single target number; it is that letting the OS govern the CPU is worth a double-digit percentage of idle draw.

On Dell, the setting that unlocks this is in System BIOS, System Profile Settings. The default profile is Performance Per Watt (DAPC), where the firmware manages processor power states. Change it to Performance Per Watt (OS), which hands C-state and P-state control to Linux so the kernel’s frequency scaling can idle the cores down. Confirm that C States and C1E are enabled, since those are what let the CPU drop into deep sleep between bursts. Turbo can stay on; turning it off lowers peak draw and peak fan noise but has little effect on idle. On the Proxmox host, verify the governor is scaling with cpupower frequency-info and that the cores actually drop to their minimum frequency at idle.

If you plan to pass a GPU, an HBA, or a NIC through to a VM, enable IOMMU while you are in the BIOS (the setting is under Integrated Devices, Virtualization Technology) and add the kernel parameters on the Proxmox host. Open the GRUB defaults:

sudo vim /etc/default/grub

Set the command-line line to enable IOMMU in pass-through mode, which leaves the host’s own devices untouched:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

Apply the change with update-grub, then reboot:

sudo update-grub

On a ZFS-root or UEFI install that boots with systemd-boot instead of GRUB, put the same parameters in /etc/kernel/cmdline and run proxmox-boot-tool refresh instead. The rest of the passthrough workflow, and the other things worth setting on a fresh hypervisor, are in the guide on what to do after installing Proxmox VE. Power is also where the rack itself matters: a metered rack PDU is the only way to see whether the tuning above actually moved the wall draw, rather than guessing.

What to watch on the temperature sensors

Lowering the fans is only safe if you watch what happens next. Two commands read everything that matters. The first prints inlet, exhaust, and per-CPU temperatures in degrees C:

ipmitool sdr type temperature

The second prints the per-fan RPM, so you can confirm the fans actually settled where you set them:

ipmitool sdr type fan

Watch the CPU temperatures under real load, not at idle, because a box that sits at 40 degrees C doing nothing can climb fast under a transcode or a VM spinning up. The margin that matters is the gap between the CPU temperature and its throttle point; keep it comfortable rather than chasing the last few decibels. On noise itself, one measured before-and-after exists in the community: a small 1U Dell R330 dropped from around 50 dBA at idle with stock fans to about 40 dBA at 20 percent. A 2U dual-socket R730 starts louder and drops proportionally, but treat any exact number as configuration-dependent. If the temperatures ever look wrong, the single command that ends the experiment is ipmitool raw 0x30 0x30 0x01 0x01, which gives cooling back to the server and buys you time to raise the floor.