Wiring a UPS into a two-node cluster with NUT

Aug 17, 2026 5 min read

A UPS does not protect your data. It buys you time to shut down cleanly, and only if something is watching the battery and acting on it. Without that, a UPS just moves the moment of the unclean shutdown a few minutes later.

Here is how I wired a consumer UPS into a two-node hypervisor cluster plus a NAS, using NUT — and the two decisions in it that look like mistakes but are not.

The topology: one master, everything else is a slave

The UPS speaks over a single USB cable, so exactly one machine can talk to it. That machine becomes the NUT master; everything else on the same UPS is a slave that asks the master over the network.

UPS --USB--> NAS  (NUT master: driver + upsd + upsmon)
                |
                +--net--> hypervisor node A  (upsmon slave)
                +--net--> hypervisor node B  (upsmon slave)

I made the NAS the master rather than one of the hypervisor nodes, for one reason: it has to be the last thing standing. The nodes mount storage from it. If the NAS goes down first, those mounts hang, and a hanging NFS mount turns a graceful guest shutdown into a process stuck in uninterruptible sleep. Shutdown order is the whole design here, and NUT gives it to you for free — slaves shut down, then the master waits out a hold-off timer and goes last.

Picking the driver is the actual work

Almost all the time I spent on this went into one line of config. My UPS is a Salicru SPS 1650 SOHO+, and Salicru appears in the NUT hardware list under usbhid-ups. That is the wrong driver for this model.

The listed entries are for other units in the same product family that genuinely are USB-HID devices. Mine presents a Cypress USB-to-serial bridge and speaks the Megatec/Q1 protocol behind it, so the correct driver is:

driver = nutdrv_qx
port = auto

Identify the chip, not the brand. Run lsusb and look up the vendor:product ID. A serial-bridge chip means a serial protocol driver, whatever the vendor column of the compatibility list says. Brand names in that list cover whole ranges of incompatible hardware.

One useful tell if you are on TrueNAS: the driver descriptions in the UI name the vendor’s own Windows software. Mine mentioned the tool Salicru actually ships, which was the hint that I was in the right protocol family.

Verify before you trust it. If this command returns live readings, the driver is right; nothing else you configure matters until it does:

upsc ups            # on the master
upsc ups@<master>   # from any slave, proves the network path too

Decision one: shut down on LOWBATT, not on battery

The tempting configuration is to shut everything down the moment mains power is lost. Do not. Most power events are microcuts of a second or two — exactly what the UPS exists to absorb. Triggering a full cluster shutdown on every flicker means the UPS causes more downtime than the power grid does.

I shut down on low battery, with a short timer after that threshold. Mains loss is logged and notified; it does not act. The UPS handles brief events silently, which is its job, and the shutdown machinery only fires when the battery genuinely will not last.

Decision two: the UPS does not power itself off

NUT can tell the UPS to cut its own output at the end of a shutdown sequence (powerdown). It is generally recommended, because it guarantees everything is truly off and that machines get a clean power-on when mains returns. I have it disabled, deliberately.

The reason is a hardware limitation worth checking on your own unit: this UPS has no switchable outlet groups. There is no outlet.* variable in upsc output at all — the sockets are one single bank. Other things hang off it that must stay alive during an outage, including the networking that lets me see what is happening. Cutting output would kill those too, to protect machines that are already safely shut down.

So the trade is explicit: if power returns before the battery is exhausted, the UPS never cycles, and the NAS and both nodes have to be powered on by hand. I accept a manual restart to avoid taking down equipment that had no reason to go down.

Check for outlet groups before you plan around them. upsc ups | grep outlet — if that comes back empty, per-group control is not a feature you have, and any design that assumes it will fail in the one situation you built it for.

What to test, because you will only find out for real once

The failure mode of this whole setup is that it silently does nothing during the one outage that matters. Two tests, neither of which requires pulling the plug on production:

The communication test. From each slave, run upsc ups@<master>. If a slave cannot reach the master, it will never receive the shutdown signal, and nothing in its own logs will complain about it while power is fine.

The full drill. Once, with a written shutdown and startup procedure in hand, pull mains and let it run to low battery. Confirm the order: guests stop, slaves power off, master powers off last. Then bring it all back and note what did not start on its own — anything with autostart disabled, anything that depends on a service that comes up slower than it does. That list is the real output of the exercise, and you want it discovered on a Sunday afternoon rather than at 3am.