@tuckertt Are both AD domains in the same forest?

@McHenry Can you put the paging file on a separate disk, and then tag that disk not to be backed up?

@Tristis-Oris My setup is similar to yours, and I get similar errors on any existing backup job.

However, if I create a new backup job, then it works without any error.

ping @florent , maybe these data points are useful.

Like @Tristis-Oris , my first tests were done using a clone of my production XO. They failed with "No NBD" errors.

Creating a new backup works.

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

@Bzyk47
Could you take your home PC to the office for a week?

1. Take it to the office, and install XCP-ng on it
2. Migrate your VMs from ESXi to XCP-ng.
3. Install XCP-ng on your office server.
4. Migrate your VMs to your office server.
5. Do incremental backups of your VMs to your home pc.
6. Take your home PC back home.

This solves your bandwidth problem, lets you continue to operate during your migration, and doesn't require new hardware.

@raxa04
You should follow @TeddyAstie's recommendation. To do that, click on "Convert to HVM".

@raxa04
What's at the top of the Advanced tab for this VM?

@olivierlambert
Can we rule out extra_guest_irqs as the root cause of this problem?

https://docs.xcp-ng.org/compute/#nvme-storage-devices-on-linux