We can't answer since it's not only on us. But on our side, we have more knowledge and more capabilities than previously to make our own moves. However, we want to keep our "upstream first" philosophy and convince XS to stay close to us. That's why we spend some times to get decent pull requests and some patience to get them merged 🙂

We truly hope to share a common future where we wouldn't have to work twice on the same problems, but instead share our man power to be more efficient together. The rest is on XS team 🙂

Also, as said before, in increasing order of complexity:

I've set up a test-environment and indeed it worked. Commvault was (is?) checking for specific version/agent string when connecting to XS/CHV/XCP-ng and in older versions refused to connect to XCP-ng.

I successfully installed the agent on a proxy-vm (it uses a proxy to ro-mount the VM-VHDs and backup the content), connected the pool, delivered the VM-inventory and also ran a successful backup:
171c0956-e3e2-4fb9-a93b-48a2be6751bb-grafik.png

In other words: If you're using Commvault (11.28+) you're not any longer locked on Citrix.

Please, Please, Please make this document itself with bash variables when it comes to the various UUIDs:

So as everyone could spot, XenServer is now a dedicated business unit inside Cloud Software Group. Funnily enough, they are back with the old name, and are more independent.

IMHO, that's good news, and we hope to continue to develop our partnership with them!

It is, and it's XOSTOR 😉

Don't get me wrong: constructive feedback is ALWAYS welcome 🙂
This is just the pricing "cards", but there's already the information that you have initial setup assistance, upgrade help and direct access to XCP-ng devs. Sounds more than just "send us an email when you need". What would you have wrote then?

Also, regarding not paying the project but hire people to contribute on it: I'm very fine with it!

@KPS Hi. This thread is now inactive sop please open a new thread dedicated to your issue.

You can import the VHD file via our REST API, see https://xen-orchestra.com/docs/restapi.html#vdi-import

apologies if this was covered. is it possible to link a xcp-ng host to the netdata.cloud?

Great. Thanks for checking this. 🙂

@wowi42 Hi there. It's already in the documentation:

https://docs.ansible.com/ansible/devel/collections/community/general/xen_orchestra_inventory.html#requirements

Also, you should see an error message if it's not installed.

@Greg_E

I've used fully passive Atom Mini-ITX systems from ASrock for oVirt for the last years. Contrary to Intel's documentation they can be upgraded to 32GB of RAM and I've also added 2.5GBit RealTek USB3 NICs for a bit better Gluster throughput.

I currently have one of them running Xcp-ng, unfortunately without support for the 2.5Gbit adapter so far, but the console is working.

The RealTek source code driver is an #ifdef nightmare, it won't compile clean on CentOS7 and I had to patch an older variant by hand to make it work there. Support on CentOS 8 was also a bit shoddy, endless diagnostic messages with the built-in driver, but functional. Abandoned that when CentOS EOL got announced.

Unfortunately Xcp-ng 8.2.1 loses the display on my Ryzen 5800U based notebook, just like all other more recent hardware devices I've tried, so I'm a bit surprised the 4700U works, when it's essentially the very same iGPU: does the Minisforum support legacy boot and did you use that?

Because I'm under the impression that the display loss is related to UEFI issues.

Well, I would say it's not directly an "upstream", it's a bit more another "downstream" from Xen and XAPI project (at least that's the idea).

It's far too early to answer about XenServer, plus the fact I'm not in Citrix board 😉 So I can't tell. I know it's generating revenue, so as long there's money, things won't disappear into thin air (support contracts and so on).

Not that far, because we are not using 4.13 as it was for the initial release:

But yes, it's not using the latest Xen upstream version, for various reasons (also as 8.2 is an LTS, we try to be conservative in terms of new versions/features, stability is more important than latest Xen features).

Finally, Xen ABI isn't stable (yet), so having a more recent Xen version also means breaking stuff with other components inside XCP-ng (XAPI/xenopsd)

8.2.1 will be around with various improvements in a matter of weeks. But I don't think that's your true problem/question here.

Regarding your issue, I don't see any obvious way without digging further on why the dom0 can't mount (I bet on a network init problem in the dom0)