@olivierlambert A very good article Olivier, thanks for that !

I agree with all that points, as I have worked for a company providing support for Open Source projects, it's a such huge value to get strong beliefs and actions to allow customers to choose one or more approach and support for this to be more like a candle than hand cuffs.

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

For those that we like to try by using xe, I did this to create the correct template. I have started from a Debian 10 template, you have to replace with the correct UUID (2 VCPUs):

xe vm-install template=Debian\ Buster\ 10 new-name-label=tempforrunx sr-uuid=7c5212f3-97b2-cdeb-b735-ad26638926e3 --minimal xe vm-param-set uuid=a2d46568-c9ab-7da2-57cb-d213ee9d8dfa HVM-boot-policy="" xe vm-param-set uuid=a2d46568-c9ab-7da2-57cb-d213ee9d8dfa PV-args="" xe vm-param-set VCPUs-max=2 uuid=14d91f2f-a103-da0e-51b3-21c8db307e5d xe vm-param-set VCPUs-at-startup=2 uuid=14d91f2f-a103-da0e-51b3-21c8db307e5d xe vm-disk-remove device=0 uuid=cb5a6d67-07d5-b5ea-358a-7ee0d6e535af xe template-param-set is-a-template=true uuid=a2d46568-c9ab-7da2-57cb-d213ee9d8dfa

The template is listed when you issue xe template-list.

@mortenchristensn said in XCP-ng 8.2.1 (maintenance update) - final testing sprint:

@stormi said in XCP-ng 8.2.1 (maintenance update) - final testing sprint:

@mortenchristensn I see two mistakes here:

the process to update from 8.2 to 8.2.1 is not by using the ISO. Check the blog post.

Can it be rolled back to a working 8.2, if it is updated with "yum update" ?

Not exactly, but you can downgrade RPMs individually if really needed.

I have a server with similar motherboard running 8.1. Is that recommended to upgrade with "yum update" too ?

In this situation it's your choice. If you want to have a backup you can rollback to, you should favour the ISO.

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

there's multiple backport from upstream since then (so it's more recent than that in terms of code base) there's also XenServer/XCP patches on top of it

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)

There you go:

ubnttemp.png

It's available right now in your XOA, Hub section. Please test and report.

Note: there's a last thing we need to fix, but it's cosmetic only (VM/template name ends with "71" because we forgot to remove it before export)

They closed their patches from direct access, I'm moderately happy to change XO patch code for CH.

@axiom00 No I was not able to get it working.

No, I don't know where the problem resides exactly.

An easy way to automate VM template build, like an up-to-date packer plugin, would love a terraform ressource