@mauzilla I just read this thread and it might help https://xcp-ng.org/forum/topic/9924/vm-vcpu-allocation I've only ever run my systems with the same processor and configuration in each host, so not sure about your system. The biggest issue with a mixed environment is to keep the processors in the same family/generation, and mixing Intel and AMD in different hosts could cause issues after a migration.

In fact it's already possible In your replication job: Edit the schedule, check "Health check" box. Target the same SR than your VM are replicated too And voila!

In theory, like thinking on top of my head, an agent in the physical machine that will be able to replicate the VM files in the same format than the XO backup, with also the "machine metadata" (CPU, RAM etc.). Then, if something goes wrong, you could restore a backup as a VM from the real machine.

just bumping my post Hoping someone has some recommendations?

It is an option indeed, one of the reason is we share the revenue with LINBIT.

@andrewperry yes, we replicate TrueNAS to a "standby" TrueNAS using zpool / truenas replication. Our current policy is hourly. We then (plan) to do Incremental replication of all VM's to a standby TrueNAS over weekends giving a 3 possible methods for recovery. Currently we're running into a major drawback with VM's on TrueNAS over NFS (specifically VM's that rely on fast storage such as databases and recordings). We did not anticipate such a huge drop in performance having VHD files over NFS. We're reaching out to XCP to ask them to give us some advice as it could likely be in part due to customization we can make.

You can lazy umount a failed network share, then PBD unplug will work.

@lawrencesystems Thank you for the reply! I considered BHC in the past, wasn't sure to how big to make the SR for the restores BTW Love your XCP YT content, helped me understand so many features and best practices

I can't say for sure as I haven't tested it, but it may "just work" if you swap them out, a lot of systems do support swapping SFP modules without extra work being done. But again, never tested it at all myself.

I'm using ZeroTier and access works, except for the console view.

@olivierlambert whoops! Well spotted Will post in the real one

@mauzilla There is no easy way to achieve that, it requires updating a number of other_config entries manually. If you have a paid subscription, open a support ticket and I'll take care of it for you

You can try to "attach" broken VIF to some network and then delete it. Try to use this command xe vif-move If that doesn't work, you can shut down the XO VM, detach the disk, deploy a new VM without a disk, attach the XO disk to the new VM.

works like a charm, thank you gents!

@dredge999 yeah in hindsight thats what I should have done I wonder if I can restore the config files and have the VM operational again. It's more getting it to stop now without a host restart

@mauzilla I personally think having the CR job operate between 2 different pools is a better idea. I am curious though, are these servers located in the same physical location? If so why not try going with high availability instead of a CR job? https://xen-orchestra.com/blog/xenserver-and-vm-high-availability/ I haven't really done HA setups with XCP-ng before, so can't really speak to how good it is. But IMO CR and other backup jobs like that are more meant for geo replication and stuff like that (i.e. a disaster recovery scenario with some offsite XCP-ng host). Which is why I'm asking about location, personally don't see the benefit to CR if in the same physical location, I'd be more interested in HA at that point. This is just my two cents though.

Yes you can do that, there's a tag on a replicated VM to avoid being replicated again.

The XO team is also bringing the magic!

@olivierlambert Based on what you mentioned about losing everything and rebuilding, if you reconnect to the NFS share, will you be able to see the VMs listed below, or would additional steps be required to recover them? Thanks! [image: 1733646346634-a2bede49-af10-45e8-9014-7c70143688cf-image.png]

@kevdog You can force a host to be ejected even if the host is not reachable any longer from the pool master using: xe host-forget uuid=UUID If there is any issue because VMs are thought to be running still on that host, you may need to do a power state reset on such before you can get rid of that host. See if that works for you.