@stormi Thanks! @olivierlambert @TeddyAstie I am unable to test further since I don't have a 'passable'/'assignable usb controller which can be passed through. Have ordered one and would keep you guys posted once I get it and test it. Though I can confirm that the bug (dunno if it is the driver / xcp-ng) persists.

@uberiain said in XCP-ng Center 25.04 Released: Hi, with this modification on MainWindow.cs in private List<TabPage> GetNewTabPages() adding this at the end: This will add the tab back in XCP-ng Center but I don't think it works in XCP-ng 8.3. I just upgraded from 8.2.1 to 8.3 when I logged into XCP-ng Center I saw the error message Active Directory authorization is not available","Server 'xcp-ng-TEST' has failed to connect to the Active Directory server. INTERNAL_ERROR: [ Xapi_systemctl.Systemctl_fail(""INTERNAL_ERROR: [ Subprocess exited with unexpected code 1; stdout = [ ]; stderr = [ Job for winbind.service failed because the control process exited with error code. See \""systemctl status winbind.service\"" and \""journalctl -xe\"" for details.\n ] ]"") ]","xcp-ng-TEST","Jul 11, 2025 3:58 PM"," # systemctl status winbind.service winbind.service - Samba Winbind Daemon Loaded: loaded (/usr/lib/systemd/system/winbind.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2025-07-11 16:01:28 AEST; 3min 15s ago Docs: man:winbindd(8) man:samba(7) man:smb.conf(5) Main PID: 9593 (code=exited, status=1/FAILURE) Status: "Starting process..." I haven't figured out what to do yet. None of the users can log into XCP-ng Center using their Active Directory credentials and only root can log in. EDIT: Actually winbind wasn't even used in XCP-ng 8.2.1, I'm not sure why this service started up in 8.3. XCP-ng 8.2.1# systemctl status winbind.service ● winbind.service - Samba Winbind Daemon Loaded: loaded (/usr/lib/systemd/system/winbind.service; disabled; vendor preset: disabled) Active: inactive (dead) Docs: man:winbindd(8) man:samba(7) man:smb.conf(5) But I can see that windbind is used for XenServer 8.4 https://docs.xenserver.com/en-us/xenserver/8/users Anyone got suggestions on how to get AD authentication working with XCP-ng Center again? Or add users manaully? SOLUTION: What I found after following the steps in the in the XenServer page above is that if I disable AD Authentication then re-enable it then it will work. To Disable AD Authentication: xe pool-disable-external-auth Enable AD Authentication: xe pool-enable-external-auth auth-type=AD service-name=full-qualified-domain config:user=username config:pass=password Without the Users tab in XCP-ng Center, CLI command is needed to add or remove users. Refer to the XenServer page above. xe subject-add subject-name=entity_name

@dinhngtu I went from Citrix 9.3.3 to 9.4.1, and generally they have remained manual when I've upgraded. All these VMs started out with 9.2.x so this is probably the fourth update to them. And all that said, I know the MAC address did not change, because I had a reservation for one of them and it was found properly before putting it back to manual. I think the XCP-ng side of things worked properly (no MAC change), but the driver side was the issue, and nothing you can fix since you don't write this driver. I probably should have used the cleaner first, but I went straight to the Citrix installer like I've done in the past. Took about an hour to get the 5 VMs updated, now I can move on to other things that have been lacking. I've mentioned it a few times, but this construction has me way behind for the summer, and only a few weeks of work time left before students come back.

@dinhngtu Thanks and good point. After my previous post I did stumble across some info (can't find the links) that suggested something similar. If I'm remembering correctly, the basic idea was the flash/NVRAM memory on the motherboard, which stores boot entries, is limited. If it's full, it's possible / may be necessary to do some cleanup using the bios itself or utilities available for Linux (efibootmgr) and Windows (bcdedit). I've not tried this myself as our install is working properly, but perhaps that can help someone else in the event they stumble across this particular issue.

@Danp Oh thanks, that makes sense, though I am not sure how I got it to work in the POC... Cold migration will be fine for the time being anyway

@yllar Maybe it was because of the loopdevice not being completely created indeed. No error for this GC run. Everything should be ok then

@MW6 You've lost two disks in a single array, you're data is lost. Time to restore from backup.

@olivierlambert The only place running XCP-ng on things like an RK3588 make sense is for home lab stuff, I probably wouldn't even build work lab stuff on these. Never enough ram (so far) and limited cores, plus almost everything will need to be running in virtual processor architecture. All that said, it might be neat to simulate these ARM processors in x86 so that we could create a VM of the Pi, etc.

On the VMware side, it's possible VMware doesn't set the right mode, so try to boot in BIOS or UEFI to see if it boots.

@igor You are welcome !

@john-c As I mentioned in the release notes, @dinhngtu told me (and tested) that if Secure Boot is enforced, then Bitlocker doesn't fail on unexpected firmware changes. Maybe worth giving it a try?

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

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