@the_spice @bullerwins @xerxist @hawkpro @vhaelan @ovicz Hi I published a post this morning with packages to test iGPU passthrough, if you have a non production host on which you can test it would be awesome: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers Thanks! Regards, Yann

@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: 603fbea0-1c07-45b8-a005-54c100a74663-image.png]

@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