@Hannes_5253 awesome! Thank you for this posting, it's helping me to get a nut client installed. Note for folks coming across this later I needed to use the following to install the nut-client:

yum -y install nut-client --enablerepo=epel

It would be cool if xcp-ng came pre-installed with nut-client and a default configuration that shuts down the xen server & turns off the ups after it finishes shutting down... similar to how truenas has a service which can be enabled to do so. You'd have to configure it of course, with the nut server to monitor, credentials, and some other options such as whether to actually powerdown the ups after shutting down or not, but maybe through a nice gui after turning it on. Seems like everyone should be using this setup ... just a matter of time till they are ready to.

Another reason this would be nice to be integrated, is that docs recommend setting up a user account for nut, one for the monitor so clients can access and another for the shutdown so one of the watchers doesn't change the shutdown script & nut provides a file that indicates when the ups should shutdown, so having that be the same on all xcp-ng systems rather than custom solution would be good.

@Hannes_5253 awesome! Thank you for this posting, it's helping me to get a nut client installed. Note for folks coming across this later I needed to use the following to install the nut-client:

yum -y install nut-client --enablerepo=epel

It would be cool if xcp-ng came pre-installed with nut-client and a default configuration that shuts down the xen server & turns off the ups after it finishes shutting down... similar to how truenas has a service which can be enabled to do so. You'd have to configure it of course, with the nut server to monitor, credentials, and some other options such as whether to actually powerdown the ups after shutting down or not, but maybe through a nice gui after turning it on. Seems like everyone should be using this setup ... just a matter of time till they are ready to.

Another reason this would be nice to be integrated, is that docs recommend setting up a user account for nut, one for the monitor so clients can access and another for the shutdown so one of the watchers doesn't change the shutdown script & nut provides a file that indicates when the ups should shutdown, so having that be the same on all xcp-ng systems rather than custom solution would be good.

Kubernetes, being a declarative approach to infrastructure, has something called 'clusterapi' which allows a kubernetes cluster to be defined as 'yaml'. The yaml file is applied, and after awhile you have the defined kubernetes cluster. Later, the yaml file could be updated to add another node, or change the version of kubernetes, and again, after applying the yaml the existing kubernetes cluster would be updated adding a node or updating the nodes with the specified kubernetes version.

Kubernetes generally has multiple nodes, vms, and so this process requires integration into the vm server environments, this is accomplished through 'providers'.

Perhaps we could get on the roadmap to add an 'xcp-ng' provider:
https://cluster-api.sigs.k8s.io/reference/providers.html

Using this method allows the management of the lifecycle of kubernetes clusters without having to drop out of the world of kubernetes to use a tool such as ansible or terraform.

I noticed there was a clusterapi provider for xenserver for the apache cloudstack project, maybe all the code is there to support xcp-ng and could be pulled out to create an xcp-ng provider not dependent on the apache cloudstack project? https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack

Additionally, having 'xcp-ng' on that list would gain attention as people will look at the list of supported providers and then go google the projects.