Then reboot than broken host and in the meantime, re-issue the power reset command from the master.

I had a similar issue, and what helped me was routing update traffic through Static Residential Proxies to avoid deep packet inspection that was blocking some repositories. They worked better than regular proxies in our setup since they look like normal home users, so the network didn’t treat the traffic as suspicious. You might need to whitelist some domains manually though, depending on how strict your proxy rules are.

That's very clear, thank you for your prompt response!

It might record the max static RAM (IDK)

@DustinB Thank you. I understand, it's absolutely a cosmetic request.

@olivierlambert did not check that unfortunately, since it it is already setup now, will be hard to reproduce it

@Cygace Someone from the community may jump in and help troubleshoot this. The best approach would be to not modify the Dom0 installation by installing Zabbix via a community post, as you're customizing the installation. The vates team and XCP-ng specifically need to include these packages to ensure you're able to get support. Best of luck

@cgasser are the backup job running normally (if any ) ? can you disable temporary the backup network ? the rrd stats should be visible immediately afte if this is the root cause

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

@Danp Hi, I'll try this. Thank you very much. Best regards Mattmurdock78

@Danp Thank you.

looks good Xen Orchestra, commit 384bb Master, commit 384bb thanks for quick fix

@AlbertK said in XCP-ng - XOA vs. XOCE: @Danp , Is it possible to add the comparison of the XOCE together wit XO in this page?. https://vates.tech/pricing-and-support/#features-matrix XOCE is a term that I came up with when I originally started writing the deployment script that exists today. It's stuck around. Vates uses the terms XOA and "XO from Sources" as their unique products. XOCE would be "you used a github script to deploy" (my github) XO. XO from Sources is a completely manual process where you're following the documentation to deploy XO. This approach gets you the same thing that XOCE does, but takes longer to complete since you're finishing each step over SSH rather than running a single bash command on a Ubuntu/Debian VM.

That's why XO proxies are great and the go-to solution Alternatively, you can deploy an XO inside the target network and manage your hosts from there (but you won't have the unique central console with one XO+proxies for the entire infrastructure)

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

I will create a new thread from your message

@AtaxyaNetwork It is Debian 12. I found the problem and will post again if there's more issue. The VM stopped using its static IP, not sure how that happened, but I re-added it to /etc/network/interfaces and it's working again.

Hi @Andrew. This PR should fix your issue https://github.com/vatesfr/xen-orchestra/pull/8854 MathieuRA opened this pull request in vatesfr/xen-orchestra closed fix(xo-server): fix incorrect state when remove server #8854

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