@BenjiReis I've finally taken the time to review this again now that I've updated to 8.3-rc1 via yum update, so here's some follow-up on the points I brought up previously:

There is no way to configure IPv6 on the management interface via xsconsole, such as if one wants to switch between static configuration, autoconf via RAs, or DHCPv6.

True but we'll soon release an new version of xsconsole adapted for IPV6 allowing to configure IPv6 for management interface 👍

There is apparently no support for IPv6 DNS servers, only IPv4. For example, if I try to add an IPv6 address like fd00::1 or [fd00::1] as a DNS server via xsconsole, there is apparently no change to the configuration. Editing /etc/resolv.conf works to achieve this (e.g. adding the line nameserver fd00::1), but this is known not to persist across reboots.

Should be solved by the future xsconsole release as well 🙂

Still not seeing any enhancements/changes in behaviour as of xsconsole 11.0.6-1.1.xcpng8.3.

There is apparently no support for RDNSS (advertisement of DNS servers in RAs rather than via DHCPv6).

DHCPv6 is one of the major blindspot for now indeed, I'm working on it but I don't have much knowledge on this so any hints are welcome if you spot if something is missing somewhere.

Just to clarify, this isn't related to DHCPv6, but RAs (Router Advertisement packets). I personally don't have a DHCPv6 server on my network at all. RDNSS is described in RFC8106.

Others may want to advertise DNS servers using DHCPv6, though, so that should still be tested as well.

The "autoconf" option (available during installation, after choosing IPv6-only or dual-stack, and then being asked which mode to use to configure IPv6 addresses) appears to only be used at installation time to determine values such as the gateway's link-local address, the available address prefixes, and perform SLAAC and DAD, but then the resulting values are hard-coded and don't change according to changes in the environment, such as an upstream change in network prefix. (I will need to do some more testing to really confirm this, but this seems to be the case in my experience.) Compare this to when IPv4 is configured to use DHCP(v4), in which the management interface may have a different IPv4 address at different times, namely if it's assigned a different address by the DHCP server when it attempts to get or renew a lease.

I'm not aware of this issue, i'll try to reproduce in our env.

I haven't been able to reproduce this either, and my prefix has changed a couple of times since I said this was an issue. Perhaps I just imagined it, hit a weird edge case, or didn't wait for the valid lifetime of the old prefix to expire; my router doesn't reliably advertise the fact that an old prefix is no longer valid.

Some repos are unreachable in IPv6-only environments, which I'm aware is already known, and I can get around this by using NAT64 (either with CLAT to perform 464XLAT; or with DNS64), but this fact is currently a blocker for me to move to being IPv6-only.

We contacted the mirrors many times, still trying to have'em all advertising IPv4 and 6 and also trying to find a solution that could "smartly" redirect towards a compatible mirror.

@stormi said in IPv6 support in XCP-ng for the management interface - feedback wanted:

FYI, I have finally reviewed all mirrors that provide updates for XCP-ng and disabled the remaining 6 which didn't support IPv6 (and notified their owners. I'll enable them again if they enable IPv6).

So, if you experience any issues installing updates via IPv6, tell us so that we investigate faulty mirrors.

I personally haven't had any issues reaching repos since then, but I haven't explicitly tested this or looked through the mirrorlist. I also don't think this is much of an issue in practice, since 464XLAT can be used; this is no longer a blocker from me, as I've reviewed the way I'm deploying IPv6-only. It's very nice to see you motivate / put pressure on mirror maintainers to make their sites accessible over IPv6 though, especially indirectly by simply removing such sites from the mirrorlist.

Speaking of NAT64, this is just a question, I haven't tested or looked into this myself: Does XCP-ng include a CLAT daemon and support for auto-configuring 464XLAT using either the "PREF64" RA option (RFC8781) or resolution of ipv4only.arpa via a DNS64 server (RFC7050)?

Haven't tested either for now, feel free to do and report if you get here before me.

I've got this working pretty easily by manually installing clatd from GitHub and its dependencies from EPEL and the other RHEL repos. It works, but isn't native. That being said, I don't know of any other Linux distros that natively support this yet. To my knowledge, there is ongoing work to implement this directly in Systemd. Clatd supports RFC7050, but doesn't support PREF64/RFC8781 as it's not particualrly feasible for it to do so, but hopefully Systemd is able to if/when it implements a CLAT.

This also isn't reliable across reboots / DHCP lease renewals because I have no simple way to disable IPv4 on the management interface. I haven't tried this with an installation where I've selected "IPv6-only" in the installer.

One practical issue I've experienced when using 464XLAT in this way is that XO Lite tries to contact the pool server in the frontend / client / web browser using JS fetch calls for URLs falling under https://localhost/, which would instead usually be under https://<pool server IPv4 address>/. These are the addresses that XO Lite will prompt the user to ensure that the browser trusts TLS certificates for if they are self-signed and no known CA has issued/signed them. As such, these don't work, since "localhost" from the XO Lite user's perspective isn't the same machine as the "localhost" that XO Lite is running on. If XO Lite supported making these calls using any of the pool servers' routable IPv6 addresses (e.g. ULAs or GUAs, but not LLAs), this would work just fine.

I may find some time to test these things on an "IPv6-only" installation, but I expect that will be after 8.3 has reached general release.

Latest XenCenter 2024.3.0 does not work with XCP-ng 8.2

@olivierlambert said in Feedback in regards to upcoming XO update:

I'm not sure to get what you said. Right now, we have a specific partnership with 2CRSi, having access to their engineers who design the case and integrate the components inside. This helps us to give exclusive insight on the hardware, and on their side, providing XCP-ng pre-installed.

I'm not against having other partners, but you can imagine that Dell or HPE are taking more time to provide XCP-ng pre-installed on it. I never heard of NovaTech before, I'll be happy to work with them if they want to work with us 🙂

I have dropped a message to Novatech with a link to your website letting them know about you. They're currently closed for today but when their people come in tomorrow they'll get my message, be ready during that day onwards for possible contact from them!

Your already got a French municipality as a customer providing their servers with your Virtualisation software stack. Well if you manage to partner with Novatech you'll also have the capacity to gain MBDA along with Thales as customers through them!

They're a solutions producer and provider partnering with them would allow both of you to benefit, as well as incorporate XCP-ng, XOA and/or XOSTOR into the Novatech solutions. Each of the solutions provided by Novatech is bespoke to a specific customer, built using off the shelf commercial components.

Pay attention to their video "Our Story #3 About Us" as they provide worry free computing to the companies working to change the world we live in. All of their people enable their customers to do remarkable things. What's more worry free than not having to worry about, a business's product policy of their closed source proprietary software?

Partnering with them would enable their products and solutions to have Vates VMS as a component to them and reduce the worries of the Novatech customers!

We will make a blog post on XCP-ng, because most of the article (especially the title) is click bait.

@dthenot said in LargeBlockSR for 4KiB blocksize disks:

Hello again,

It is now available in 8.2.1 with the testing packages, you can install them by enabling the testing repository and updating.
Available in sm 2.30.8-10.2.

yum update --enablerepo=xcp-ng-testing sm xapi-core xapi-xe xapi-doc

You then need to restart the toolstack.
Afterwards, you can create SR with the command in the above post.

Update: now the driver is available on any up to date XCP-ng 8.2.1 or 8.3. No need to try to update from testing repositories (you might get something unexpected).

@olivierlambert Awesome! Thank you so much!

@Toni I also now personally avoid Google where it's possible to do so, but before starting to do so, it was only capable of translating text not images!

@olivierlambert thanks for confirming!

Wow this great news and amazing work!!! 🙂

@olivierlambert Business 2 pools updated fine.

@olivierlambert I am open to building stuff into XCP-ng if my knowledge was there to do it.

@gskger XCP-NG on ARM/Ampere will be huge!!!!
The running cost of those machines is a big win over x86. Power is expensive in Europe. Hetzner is in full swing on that front.
And not everything runs in Windows 😉 I guess it's only the smaller fraction of all the VM's in the world.

@olivierlambert said in Dell cancels VMWare contract after Broadcom purchase:

Time to make a phone call to Dell 👼

Yes sir do it. I hopefully a contract between you / Vates and Dell is on the horizen. Really hope XCP-ng comes as the standard for Virtualization just like ESXi once was.