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

@stormi Thanks, I was wondering if that was the case from reading the other threads.

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

@olivierlambert Thanks for your reply. Since this is just a spare server, I decide to perform a new fresh install. Previous install of Beta was easy (I think that it was via Bios) but this final release causes a lot of trouble: in UEFI no success, even after wiping all the SSDs with Gparted-live-cd (because XenServer and XCP-NG have sometimes trouble to remove flags from ZFS, Raid, LVM or others, according to olders posts. in Bios mode, install works but one NVMe of two is not detected (the one seated on a U2-pcie adapter) Now I'm facing a hardware problem known of these DELL Rx20 (server halted at boot) with a pcie adapter. So I'm trying to shutdown for a while the machine via the IDRAC and try a cold boot. If not working I have to reseat PCI riser as it is advised in many forums. This prevent me to upgrade via iso two productions servers (DELL R520 and R820) before having solved the current issue on the backup machine.

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

@olivierlambert Awesome! Thank you so much!

@olivierlambert thanks for confirming!

Wow this great news and amazing work!!!