@florent I'm doing this from source.
Running git pull --rebase seems to have fixed the build problems.

@yzgulec
You might build your first pool using your existing rules (eg, pCPU:vCPU = 1:3). As business expands, you will gain experience that allows you to adjust your rules when building future pools. I would be interested in hearing what you find.

Be sure to give the control domain (aka "dom0") enough RAM.

The hosts in a pool should all be the same - same CPU type, same number of cores, same amount of RAM, same number of network ports, and a consistent network design.

@kassebasse said in Remove running host:

I am just trying to remove the host, because it is no longer exists

In that case, try

xe host-declare-dead

You will need the prior UUID of the host, that is, the UUID assigned to the host before you reinstalled xcp-ng.
xe host-list will provide that.

Read the warnings about host-declare-dead carefully.

The existing technical documentation is great. An operations guide would be helpful. Here are a couple of chapter ideas:

1. Best practices for setting up your environment
   (eg, odd number of hosts, isolate management network, treat your hosts like cattle, etc)

2. Preparing for disasters (eg, requirements for restoring pool metadata, how to recover a single VM if your pool data is gone, etc)

Testing a continuous replication backup, I get Error: can't connect to any nbd client

Running the same job on my regular XO works fine. Let me know what logs you want to see.

mail (h2)

   Snapshot
   Start: 2025-04-10 18:18
   End: 2025-04-10 18:18
   h3 local storage (130.02 GiB free) - h3
   Start: 2025-04-10 18:18

Start: 2025-04-10 18:18
End: 2025-04-10 18:18
Duration: a few seconds
Error: can't connect to any nbd client
Type: delta

@florent I'm doing this from source.
Running git pull --rebase seems to have fixed the build problems.

I'm still getting "Cannot find module '@vates/generator-toolbox'" errors when I try to build it. I'm using the 'feat_generator_backups" branch.

I found this while investigating repeated backup failure reports. The error report says "NO_HOSTS_AVAILABLE()".

I finally noticed that the user had removed all of the disks from the VM.

Could the backup code be adjusted to ignore VMs that don't have disks, or to return a different error?

@RawbDeeni
Can your XCP host ping xoa.io?

@kagbasi-ngc
First, a disclaimer. It's been a while since I last designed an HA solution for AD. Things may have improved.

You should reconsider your approach to designing a highly availability AD. Configuring the client to guess which AD server to use will work fine, but only as long as both AD servers are healthy. If there is ever a problem between them, you will have no control over which AD the servers hit.

If I remember correctly, best practice for highly available Active Directory is either to use Microsoft's AD VIP solution, or to use round-robin DNS (multiple records with the same name but different IP addresses). Either way, all of the clients in a single domain should have the same configuration.

@yzgulec
You might build your first pool using your existing rules (eg, pCPU:vCPU = 1:3). As business expands, you will gain experience that allows you to adjust your rules when building future pools. I would be interested in hearing what you find.

Be sure to give the control domain (aka "dom0") enough RAM.

The hosts in a pool should all be the same - same CPU type, same number of cores, same amount of RAM, same number of network ports, and a consistent network design.

@julien-f said in Enhancement suggestion: Filter showing VMs that don't have the agent installed:

XO does not support this for halted VMs but that could be added indeed.

Can you change the title of my thread to "Enhancement suggestion: Update 'ManagementAgentDetected?' to support halted VMs" ?

A filter that only lists VMs that need the agent installed would be very helpful. Here are a few thoughts.

1. The "has agent" mark should persist after VM shutdown. Can we use tags, or should we look for an alternative?

2. VMs that have the agent running should be marked as having the agent. Can we update the agent so that it add the tag itself at startup?

3. XO should remove the marker from any VMs that have been running for more than 5 minutes and do not have the agent running.

With this setup, it is easy to determine which VMs need the agent, including VMs that are shut down at the moment.

@davealex8
Any hardware changes to your server, or on your network?

What's your setup?

• How many servers?
• What type of CPU?
• Where is your VM storage (in the server, on an NAS, on iSCSI)?

Go slowly, take the time to make a plan, and you're more likely to recover.

-David