@scawtydont Thanks for keeping us posted. Dummy plug is still a thing it seems

@shinuza The version inside the Debian image and the version on GitHub may be different. It is likely that there will be more recent versions on GitHub. Just don't select a version and the latest version from the Debian repository will be installed. const k8sInstall = k8sVersion !== undefined ? `apt-get install -y kubelet=${k8sVersion} kubeadm=${k8sVersion} kubectl=${k8sVersion}` : "apt-get install -y kubelet kubeadm kubectl";

Depends on what you expect from "manage", but once a template is deployed (or recipe applied), it's all regular VMs.

Just updated to lastest commit https://github.com/vatesfr/xen-orchestra/commit/4bd5b38aeb9d063e9666e3a174944cbbfcb92721 It's fixed now. Working wonderfully. Thanks! [image: 1683882828176-603fbea0-1c07-45b8-a005-54c100a74663-image.png] 0 fbeauchamp committed to vatesfr/xen-orchestra fix(backups): fix health check task during CR (#6830) Fixes https://xcp-ng.org/forum/post/62073 `healthCheck` is launched after `cleanVm`, therefore it should be closing the parent task, not `cleanVm`.

@julien-f said in XOA Proxy Error when updating: @bullerwins XO Proxy Appliance deployment is not supported in XO built from sources. my bad, it used to work a few months back I believe @olivierlambert said in XOA Proxy Error when updating: I missed that in the original message, indeed FYI @bullerwins there's no such thing as XOA built from sources, you have either: XOA is Xen Orchestra virtual Appliance, that's the VM we distribute with pro support and QA/stable channel, updater and such XO from the sources is from Github, without pro support but community support, no QA no stable version, no udpater and such Thanks, I got confused with the naming, I'm using the second option. As a workaround I used a VPN to manage the remote XCP-ng host, thanks!

We made the proxy with the smallest attack surface possible, so I would say it's pretty safe. But indeed, and as usual, it's a perpetual balance benefits and costs