Posts made by lknite

Hello, I had a pool with two servers called 'one' and 'two'. One was the master of the pool. I moved all vms from host one to host two and then repurposed host one not realizing that I could no longer access 'two' via XCP-ng Center. It tells me that 'two' is part of a pool and asks if I want to connect to the pool master, 'one', which of course does not exist.

I've read in the forum a similar question to this but it almost sounded like the commands given would remove all the vms from the host.

One of the vms on host two is not responding, all the others seem to be ok, I attempted to list the vms via the cli so I could reboot it but 'xe vm-list' isn't responding.

How can I safely remove 'two' from the pool so I can access it via XCP-ng Center? I'm guessing this may also fix the 'xe vm-list' not responding.

---

kept searching, found another article:
https://xcp-ng.org/forum/topic/4075/pool-master-down-what-steps-need-done-next

this command seems to have me back up:
xe pool-emergency-transition-to-master

@AlexanderK hello fellow user of cloudstack, did you find that you had to enable bridge mode on your xcp-ng servers to get cloudstack to work with them?

@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.