similar to: Running nut-monitor under XCP-ng

Is anyone using snmp-ups with the -k option successfully? This is really starting to look like a bug somewhere in nut, not a config problem. I've just tried the same command from a FBSD box with the same unfortunate result. Mind you, it could be the UPS card, I'm using the same one for both tests. : || nomad at castle nut-2.7.4 [93] ; please drivers/snmp-ups -a nutdev1 -x

With XCP how do we autostart a VM when a host boots up? In Xen I would have made a symbolic link to the VMs config in /etc/xen/auto/ Also does anyone know why LVM is disabled in the /etc/rc.d/rc.sysinit in XCP 1.1 beta? I uncommented it and when my Host boots it does a vgchange -ay now and the LV gets mounted in the fstab. I can''t think of a reason why this isn''t the default

I meant to send this to the list but evidently only sent it to David. Since sending it I've done a second test which shows what a successful snmpset looks like. First attachment, from the forwarded email, is nutout.txt. Second attachment is snmpout.txt. nomad -------- Forwarded Message -------- Subject: Re: [Nut-upsuser] [EXTERNAL] SNMP shutdown timing out Date: Mon, 4 May 2020 09:28:57

On 4/28/20 1:58 PM, David Zomaya wrote: > snmpwalk -l authpriv -v 3 -u user -a MD5 -x DES -A authpassphrase -X > privpassphrase Evidently, even with argument identifiers order matters. That worked just fine and dandy. Now I guess I need to play with the order of the nut-scanner arguments to see if I get a similar result. thanks, nomad

I'm still digging into this but thought I'd post what I have so far in case there's a known issue that's easily fixed. I'm using the version of NUT that's in the ports tree (see the info at the bottom). Using the SNMP drivers to talk with two ACP SmartUPSs. NUT is functional about monitoring and initiating host shutdown. However, when it comes time to shut down the UPSs

Thanks, A "-q" (or an envvar to same effect) is another way to skin the cat, as discussed in that ticket and now followed-up by https://github.com/networkupstools/nut/issues/1789 It still leaves open the question of whether default runs of NUT programs - especially as services or shutdown hooks - should be that quiet (whether because C code is changed unconditionally, or

Thanks, A "-q" (or an envvar to same effect) is another way to skin the cat, as discussed in that ticket and now followed-up by https://github.com/networkupstools/nut/issues/1789 It still leaves open the question of whether default runs of NUT programs - especially as services or shutdown hooks - should be that quiet (whether because C code is changed unconditionally, or

*That* command would shut it down, same as `upsdrvctl shutdown` but with a better chance to debug what actually happens in the dialog. Actually with NUT v2.8.2 you can also request debug of drivers via `upsdrvctl -d -DDDDDD shutdown ups_bottom` or some such (`-d` tells it to pass debug flags to driver programs it launches). Jim On Tue, Dec 17, 2024 at 9:35?PM Lee Damon <lvd at uw.edu>

I've told systemd to wait up to 10 minutes for startup but it's still failing. Sometimes it fails with "timeout exceeded" and sometimes with the ASN error previously reported. I went back to running upsdrvctl -D to see if I could see anything. On the third run I saw messages about "startup timer elapsed" for ups2-1 and then it tried again to launch that one (killing

That's certainly on the list of options. I'm doing data gathering right now to see what options there are. I'd prefer not to rashly decide to run off in a direction only to discover this is already a Solved Problem. nomad On Thu, May 14, 2020 at 1:13 PM Bart J. Smit <bart at smits.co.uk> wrote: > What about the REST API to do a graceful shutdown of your VM’s and the >

Thanks Bart. Unfortunately "The VIB module does not comply with the security recommendations imposed by VMWare. You lose VMWare support by installing this package." This pretty much rules out this option. :( We need vCenter support, as well. nomad On Thu, May 14, 2020 at 10:06 AM Bart J. Smit <bart at smits.co.uk> wrote: > This shuts down the hosts directly (by-passing

I've been wrasslin' with a problem on a CentOS 7 host that I'm using as my main NUT server. When the battery gets low while the server is shutting down it is supposed to signal the UPS to shut down as well. This is clear, well documented, and The Right and True Thing to Do<tm>. However, the default scripts provided in the EPEL RPM aren't actually doing it. The host halts as

What about the REST API to do a graceful shutdown of your VM’s and the vCenter appliance: https://code.vmware.com/web/sdk/6.7/vsphere-automation-rest Bart… From: Lee Damon <nomad at ee.washington.edu> Sent: 14 May 2020 20:29 To: Bart J. Smit <bart at smits.co.uk> Cc: nut-upsuser at lists.alioth.debian.org Subject: Re: [Nut-upsuser] NUT control of vCenter & vServer? Thanks Bart.

Re: "Does it work well with NUT?" Assuming it is the SU5000RT4UHV, the similar units I've tried seemed to work fine. For reference, the SU5000RT4UHV should be a 4004 USB protocol. ________________________________ From: David Zomaya Sent: Wednesday, March 25, 2020 5:21 PM To: Lee Damon; nut-upsuser Mailing List Subject: Re: [EXTERNAL] [Nut-upsuser] thoughts on tripp lite Smart

Thanks. I haven't used that unit specifically with Network UPS Tools, but have used similar (from a protocol perspective) units. I'm working remotely for a while, but on the off chance I get into the position to connect a unit via USB, what Operating System are you using? If the opportunity arises, I can try to set up a basic test. Thank you, David Zomaya Business/Quality Analyst-

Is anyone using NUT to signal/control vCenter and vServer (6.x) for shutdown when batteries are getting low? Any recommendations? We've found https://4sysops.com/archives/startup-and-shutdown-a-vmware-cluster-with-powercli-and-powershell/ but I'd prefer to do this from the master (which is running CentOS 8) and not pollute it by installing PS on it. thanks, nomad -------------- next part

Hi there, I am trying to set up XCP on Ubuntu 12.04. I went through the procedure given in the README file of the xcp-xapi package and reached the point where the hypervisor seems to be running fine. I set up a VM using the Debian Squeeze (64bit) template and started it, giving a Debian mirror URL as install-repository. Running "xe vm-list" reports that the machine is running, but when

Hello, Thanks for the report and sorry about any complications. A few first questions: * is this setup known to have been working with earlier NUT releases (e.g. same OS and devices, older NUT - can try with a custom build of older tags)? Is this a regression, or we never knew the correct mappings for timeouts and/or shutdown commands used by this model? * is there the `select` error when

Good day. I found that XCP ignores VCPU-params (weight and cap) after VM live migration, as well, as those parameters ignored if changed on running VM. May I as someone with xcp cloud nearly check this bug? Thank you. -- wBR,George. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Package: xcp-xapi Version: 1.3.2-8 Severity: important Tags: patch Found race condition (specific only to slave hosts): xcp-xapi can start earlier than xcp-networkd due lack of dependency in init.d script. Syptoms: After reboot slave's xcp does not work: xe (anything): The host failed to acquire an IP address on its management interface and therefore cannot contact the master. log: