XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Performing automated shutdown during a power failure using a USB-UPS with NUT - XCP-ng 8.2

    Scheduled Pinned Locked Moved Compute
    29 Posts 12 Posters 17.0k Views 13 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • 2b2bff2 Offline
      2b2bff @olivierlambert
      last edited by

      @olivierlambert in simple words: they just don't shut down. And if they would have to there are bigger problems to solve.
      Thanks for answering...

      gskgerG 1 Reply Last reply Reply Quote 1
      • gskgerG Offline
        gskger Top contributor @2b2bff
        last edited by gskger

        @2b2bff I think that there are still some business scenarios, where this functionality would come in handy.

        For example, we are running server rooms at our main production sites worldwide (no data centers, no colo, all on-site). Each features a three VMware hosts cluster with shared storage, backup, switches, and firewalls in an air-conditioned server room with adequate fire prevention/protection. All have two power feeds (A and B or left and right as Olivier called them) and all systems have dual PSUs, but the sites usually have only one power supplier and no generators.

        Feed A goes to an UPS and feed B directly to the power line. If the power goes down, the UPS automatically triggers the vCenter, storage and backup to shut down when the UPS remaining runtime is below a certain threshold.

        But I can perfectly understand Oliviers reasoning and there are workarounds. It all depends on your risk appetite (if that is a word in English).

        2b2bff2 1 Reply Last reply Reply Quote 0
        • 2b2bff2 Offline
          2b2bff @gskger
          last edited by

          @gskger yeah same on my place. I play around with xcp-ng at home, where this is not important, and there is no UPS. So it is not important here.
          But I have built two hosts at work in a server room as well. Together with TrueNAS and a couple of other things. The APC UPS has a management card, so it can be reached via network, but somehow the hosts have to shut down gracefully if needed. That's how I stumpled upon this thread in the first place.

          1 Reply Last reply Reply Quote 1
          • olivierlambertO Offline
            olivierlambert Vates 🪐 Co-Founder CEO
            last edited by

            I'm not saying it's not important in general (it depends on the use cases) 🙂 But in our priorities (the "regular" DC world), it is not. For the "Edge computing" case, it might be more important, but the word "focus" doesn't have any meaning if we do everything at the same time.

            And as usual, contributions are always welcome!

            1 Reply Last reply Reply Quote 2
            • O Offline
              odeawan
              last edited by

              Would just having the nut client be sufficient enough on the base XCP-NG to tigger a shutdown via NUT? Maintaining the NUT server seems to be a hold up and add extra complexity for XCP-NG. We all may have different DC power situations, but we could all use tools in our belt at home or the data center.

              H 1 Reply Last reply Reply Quote 0
              • H Offline
                Hannes_5253 @odeawan
                last edited by

                @odeawan Sure but you need a nut server. When you use the XCP-NG Server as a client you have to install the nut server on a different system. You can't install the nut server on a vm on the same host because the nut server must be installed on a system to shut down last.
                So running this scenario is the most redundant and efficient way.

                1 Reply Last reply Reply Quote 0
                • O Offline
                  odeawan
                  last edited by

                  Well I still don't think it is out of scope then for just the NUT client for enterprises or HomeLabs on XCP-NG.

                  SBCs are everywhere these days. Using a Raspberry Pi as the NUT Server in a homelab or a flavor of a more robust server for NUT seems like a solid choice. No USB passthrough to worry about, uptime on a 1500VA+ UPS, forget about it! There are a handful of guides how to get it running for a Pi or anything else (including this post).

                  As I think this though, I would still feel ok with another external device watching, waiting, and notifying me on a successful power off of any number of my hosts and VMs. Not all enterprises or homelabs can afford (even if their appetites want it) to get enterprise level power automations. We have our power. Break the chain. @olivierlambert

                  1 Reply Last reply Reply Quote 0
                  • olivierlambertO Offline
                    olivierlambert Vates 🪐 Co-Founder CEO
                    last edited by olivierlambert

                    Which chain? The development is open, if you want something, do it 🙂 If you want to be the maintainer so we can have it updated, packaged and put in our repo (even if not bundled by default), go ahead! If we think there's people behind it, we are not against, since it's an extra package.

                    D 1 Reply Last reply Reply Quote 4
                    • D Offline
                      dj423 @olivierlambert
                      last edited by dj423

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • N Offline
                        nomad
                        last edited by

                        After NUT's grand reconfiguration there are a few things that you need to be aware of:

                        In order to run NUT as a monitor to shut down your XCP-ng hypervisors it is no longer sufficient to just install nut-client and enable nut-monitor.

                        You also need to install nut and enable nut.target or nut-monitor won't autostart. There won't be anything in journalctl either, since it isn't even trying to start - the thing that tells it to do so is the nut.target and if that's missing nothing will ever trigger.

                        yum install nut nut-client --enablerepo=epel
                        

                        make your edits in nut.conf and upsmon.conf then

                        systemctl enable nut.target 
                        systemctl enable nut-monitor 
                        systemctl start nut-monitor
                        
                        C 1 Reply Last reply Reply Quote 0
                        • C Offline
                          CodeMercenary @nomad
                          last edited by

                          @nomad What do you mean by the grand reconfiguration? Is there a new version that changes how things work?

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post