@olivierlambert thank for that. Just to be clear the vm was not runing but shut down if that makes a difference. @ph7 Both firewalls are Unifi Enterprise fortress gateways. - https://techspecs.ui.com/unifi/cloud-gateways/efg?subcategory=all-cloud-gateways Both sites are setup with Site Magic VPN. So should be full 1.1gbps if accurate. [image: 1767705099263-screenshot-2026-01-06-081123.png]

@myles3 Hello Myles3. This post is over 20 days old. The issue was since been resolved by support. I dont remember the exact solution off the top of my head with out looking it up.

@olivierlambert Thank you for the reply. There was a thread on here about the iso not being mounted properly and I commented about having power off the vm and back and it will load the iso. This is specifically true with the 0.4.0 for linux. Image pulled from the XO Hub will not mount the ios if the vm is powered on. There is Yellow Explanation mark next to it. Power off vm and power on vm iso is ok. Reboot vm does not let the ios to work.

@acebmxer Great. These are some YAML basics. You should read more about it . Following AI instructions without understanding is not going to take you far.

@olivierlambert Yes I previously was. now back on VHD. This was in my home lab, not work enviorment.

I had to disable Purge snapshot data when using CBT. Backups are not longer defaulting to full backups.

@olivierlambert Thought so just wanted to check. Thank you.

Helped if i read the error message.... raise RuntimeError(f"{vm_type} {vm_uuid} is {power_state}, expected Halted; refusing to fix") Shut down vm ran the fix again, and fix applied. Edit - I did have to disable secure boot on windows vms for them to boot afterwards.

Backup job still failing. I have open a support ticket - Ticket#7746281

@florent yeah that is what i did deploy xo-ce while waiting for a response. I still have 3 more vms to migrate. I so i will continue this route for the migration. Thank you for the confirmation.

@Pilow I thought restarting tool stack affected both host? Either way did try that but on host 1 originally. So i restarted on host 2 (where problem is). still no locked. I rebooted host 2 and that seem to do the trick. Took a few min for garbage collection to complete. All clean now. Thanks.

@florent and @olivierlambert I think it can wait until XO6. I dont have sperate test servers at the office so if I need to spin up a test machine i may want to back it up for testing but not to cloud backup as its only test. Tagging would make this easy since you have tagging implanted. As a work around i could create separate backup jobs for those less important vms.

Yes! That's a good guide for what you want to achieve

Thank you everyone for your feedback, really appreciated!

@acebmxer Hello, We’re aware of the Backblaze rate limits and this isn’t the first time it’s been raised. We’ll be looking into this on the XO side, studying different options such as caching restore points to reduce API calls. Longer-term improvements, possibly tied to advanced XO6 dashboards, are more of a 2026 horizon. Thanks for bringing this up!

I have no idea what this flag is doing, so my gut feeling is: no, it's not on XO side but a "problem "on the reverse proxy itself.

Before the end of this month.

@acebmxer Hello, the XO team is currently working on a solution. We will keep you inform as soon as it is on release.

@acebmxer said in Windows Server not listening to radius port after vmware migration: After migrating our windows server that host our Duo Proxy manager having an issue. [info] Testing section 'radius_client' with configuration: [info] {'host': '192.168.20.16', 'pass_through_all': 'true', 'secret': '*****'} [error] Host 192.168.20.16 is not listening for RADIUS traffic on port 1812 [debug] Exception: [WinError 10054] An existing connection was forcibly closed by the remote host After the migration I did have to reset the IP address and I did install the Xen tools via windows update. Any suggestions? I am thinking I may have the same issue if i spin up the old vm as the vmware tools were removed which i think effected that nic as well.... On your VM that runs the Duo Auth Proxy service, check if the service is actually listening on the external IP or if its just listening on 127.0.0.1 If its just listening on 127.0.0.1 you can try to repair the Duo Auth Proxy service, take a snapshot before doing so. Also, if you're using encrypted passwords in your Duo Auth Proxy configuration you probably need to re-encrypt them, just a heads up, since I just had to do so after migrating one of ours. Edit: Do you have the "interface" option specified in your Duo Auth Proxy configuration?

@DustinB That pic was taken from the host tab. But yes I removed from the settings tab and host 2 still shows under pool 1 and all looks ok. Thank you.