XCP-ng 8.3 betas and RCs feedback 🚀

JoyceBabu

I am migrating from Proxmox and have installed 8.3 beta. So far everything looks nice.

Is SMAPIv3/ZFS-ng available in this release?
https://xcp-ng.org/blog/2022/09/23/zfs-ng-an-intro-on-smapiv3/

olivierlambert

SMAPIv3 is "working", but you won't be able to live migrate the storage, export, backup etc. So it's not fully baked yet.

It's better for now to use local ext SMAPIv1 for your local disks

JoyceBabu

Thank you for the clarification. If I would like to test ZFS-ng, how can I do that?

olivierlambert

IIRC, there some hints here: https://xcp-ng.org/blog/2022/09/23/zfs-ng-an-intro-on-smapiv3/

JoyceBabu

I saw your post on https://github.com/xapi-project/xapi-storage/issues/101 about the status of SMAPIv3. I also saw another comment on the project that the code has been merged with xen-api. Is SMAPIV3 stable? When you say it is not fully baked yet, are you referring to SMAPIv3, ZFS-ng or both.

Can we expect ZFS-ng support in XCP-ng at least by 2024?

olivierlambert created this issue in xapi-project/xapi-storage

closed Is SMAPIv3 still maintained? #101

olivierlambert

SMAPIv3 isn't fully baked because:

Doesn't support live storage migration
No migration path from v1 to v3 and vice versa

But it's the future of the platform. ZFS-ng is just "one driver" written to work for SMAPIv3, which is the "framework" if you prefer

JoyceBabu

So, if I understand correctly, it seems that SMAPIv3 may currently lack some features, and until those features receive upstream support, XCP-ng might not be able to provide full support for it.

I'm curious about this because, from what I've seen, Vates has been making admirable efforts to enhance XCP-ng with new features. However, if this specific feature relies on upstream support, it might take some time before we can expect its implementation.

olivierlambert

Let's say it's harder with the upstream, since it requires a good collaboration with other entities, that might have other priorities or not really interesting in reviewing/validating your contributions. Note it's better with some projects and harder with others.

psafont

@gsrfan01 The error happens because the joining host has TLS certificate checking enabled for pool connections while the joined host don't.

This mismatch happens because on fresh installs TLS certificate checking is enabled, while for updates from previous versions is not.

To enable TLS certificate checking in a pool simply running xe pool-enable-tls-verification.

The emergency command is not needed in this case, it's useful to re-enable certificate checking in a single host after is has been disabled using the emergency disable

stormi

@psafont Will a 8.2 to 8.3 upgrade (through the installation ISO) leave TLS verification disabled, or will it enable it by default?

In other words: must we expect any user who upgrades from 8.2 or lower and then later wants to add a new host to the pool to see this error (and likely ask for help, even if we document it properly - and we would of course)?

psafont

@stormi said in XCP-ng 8.3 beta :

@psafont Will a 8.2 to 8.3 upgrade (through the installation ISO) leave TLS verification disabled, or will it enable it by default?

It's not enabled by default, enabling it by default is not possible with the current update procedure where the pool coordinator is updated before the other pool member because these do not expose the new certificates to xmlrpc clients before upgrading, breaking communications.

In other words: must we expect any user who upgrades from 8.2 or lower and then later wants to add a new host to the pool to see this error (and likely ask for help, even if we document it properly - and we would of course)?

Yes

gsrfan01

@psafont that's good to know, there were disturbingly few results when I searched for the error or the command.

This post is actually the top result for me now alongside a blog post from Oliver that wasn't there originally.

stormi

I just pushed a few updates to the XCP-ng 8.3 repositories. Update as usual.

blktap, sm, tzdata: requirements for supporting XOSTOR on XCP-ng 8.3
xsconsole: now displays VLAN number for each NIC (improvement contributed by XCP-ng users: https://github.com/xapi-project/xsconsole/pull/6)

GnomeZworc opened this pull request in xapi-project/xsconsole

closed add vlan display on xsconsole #6

gb.123

@stormi

Hi stormi !

Thanks for the wonderful release. Here are my 2 cents after preliminary testing :

Bugs Found :
The iso creates the partitions: 1,2,3,5,6 ( Partition No. 4 seems to be missing ), this is when NO SR is created at the time of install.

Improvements Found [ Over previous Releases] :
The IP is allotted much faster than in 8.3 alpha release which took a long time to set-up the network.

Other Notes:
Dual-Stack without static IPv6 does not seem to work. I don't know if this is a bug. Also if Dual-stack is selected at the time of installation, and the Router/DHCP does not support IPv6, even IPv4 is not allotted. Technically, if IPv6 is not available, then IPv4 should be allotted and IPv6 left without allotment. But in this case the whole system seems to have no network.

Test Specs :
Processor : Intel 8700
RAM : 32 GB
SSD : 512GB + 1 TB

Please note that this is a preliminary test only and I would conduct more tests soon on Ryzen 5950X also.

Thanks once again for your quick releases !

BenjiReis

Hi @gb-123 thanks for the tests

Can you be more precise with your Dual stack issue reports?

are you encountering issue during the isntall or after when XCP-ng is installed?
Ipv4 and 6 configuration are independant from one another so it surprises me.

gb.123

@BenjiReis

It was just a preliminary test.

There seems to be no problem when installing. Its just that when dual stack is chosen, and the router ipv6 dhcp is disabled, xcp-ng gets no network.

I was expecting that in case IPv6 is not available, IPv4 would get allotted. Rather if both are available, both would get allotted.

This may be a router issue, I will have to dig deeper into this. That's Why I put it to 'Other Notes' instead of 'Bug' section.

BenjiReis

@gb-123 I see, the behavior should be as you said that IPv4 would be alloted.
Can you run xe pif-param-list uuid={uuid} on your host to see what's the ip abd ipv6 onfig says?

Thx

gb.123

@BenjiReis

Actually, I have re-installed the server with ipv4 only since it was not getting network and the server was needed. But I'll try and do some tests over the weekend.

gduperrey

New Security Update Candidates (Xen and AMD CPUs) for Zenbleed

Xen is being updated to mitigate hardware vulnerabilities in AMD CPUs.

Upstream (Xen project) advisory: XSA-433
- Citrix Hypervisor Security Update for CVE-2023-20593

This issue affects systems running AMD Zen 2 CPUs. Under specific microarchitectural circumstances, it may allow an attacker to potentially access sensitive information.

As this flaw can be critical for AMD Zen 2 users, we integrated the patch into our 8.3. You can read about this vulnerability on our blog here. This update includes the latest bugfix of this patch from upstream. You can read about it here on the blog.

Test on XCP-ng 8.3

From an up to date host:

yum clean metadata --enablerepo=xcp-ng-testing
yum update "xen-*" amd-microcode --enablerepo=xcp-ng-testing
reboot

Versions:

xen-*: xen-4.13.5-10.42.3.xcpng8.3
amd-microcode: amd-microcode-20220930-2.1.xcpng8.3

What to test

Normal use and anything else you want to test. The closer to your actual use of XCP-ng, the better.

Test window before official release of the updates

None defined, but early feedback is always better than late feedback, which is in turn better than no feedback

stormi

@gb-123 said in XCP-ng 8.3 beta :

Bugs Found :
The iso creates the partitions: 1,2,3,5,6 ( Partition No. 4 seems to be missing ), this is when NO SR is created at the time of install.

Hi. I think this is on purpose, in the installer code coming initially from XenServer, so that partitions with a given number always serve the same purpose.