This is installed and working on my two test systems but they're both AMD so I'm not able to test the updated microcode.

This seems to be working fine on my two test systems but I don't do PCI passthrough.

It's installed and seems to be working well in my test pool so far, not using XOSTOR.

@leader Seems to be running just fine on my test servers as well.

@tormi

Here's the results from one of my test lab servers:

Test server: HP MicroServer
CPU: AMD Athlon(tm) II Neo N36L
RAM: 8GB

xtf-runner selftest -q --host

Combined test results:
test-hvm32-selftest                      SUCCESS
test-hvm32pae-selftest                   SUCCESS
test-hvm32pse-selftest                   SUCCESS
test-hvm64-selftest                      SUCCESS
test-pv64-selftest                       SUCCESS

xtf-runner -aqq --host

Combined test results:
test-pv64-cpuid-faulting                 SKIP
test-pv64-pv-fsgsbase                    SKIP
test-hvm32-umip                          SKIP
test-hvm64-umip                          SKIP
test-pv64-xsa-167                        SKIP
test-pv64-xsa-182                        SKIP

/usr/libexec/xen/bin/test-cpu-policy

CPU Policy unit tests
Testing CPU vendor identification:
Testing CPUID serialise success:
Testing CPUID deserialise failure:
Testing CPUID out-of-range clearing:
Testing MSR serialise success:
Testing MSR deserialise failure:
Testing policy compatibility success:
Testing policy compatibility failure:
Done: all ok

echo $?
0

@duperrey Tested and working in my lab as well. So far, so good...

@duperrey
Installed on my test lab systems, 2 very old AMD systems with shared NFS storage with a mix of different types of guests. All working so far.

@duperrey
Applied on my test systems and all seems to be working well here.

@Marc-pezin

This is fantastic news! Thanks for sharing it. Olivier mentioned that something might be in the works but didn't mention much more than that.

I've used DRBD on various projects in the past and been nothing but impressed by it. It would be interesting to see if you could reach out to the folks behind HA-Lizard as well; they've got a lot of experience with DRBD on Xen systems.

Installed on my test server, not running XOSTOR, everything seems to be working fine so far.

@eddyAstie Do you know if these can be set in XO or are they only via command line at this point? I'm curious and also curious as to how well supported because I'm looking at a possible migration from XS 7.1.2 to XCP-ng 8.3 where there are several 32-bit PV machines.

Installed on my test server, not running XOSTOR, everything seems to be working fine so far.

It's installed and seems to be working well in my test pool so far, not using XOSTOR.

@echknowbabble said in GRUB waits for confirmation:

What did finally work was re-installing with the 'no serial' option and everything seems to be working as expected now. I only have a handful of XCP-NG installations under my belt but I wonder if this is a known bug or if anyone else has had a similar experience.

It's not something I've ever seen before and I've done quite a few installations but I can think of some possibilities as to why something like that might fix the problem. My best guess is that there's something built into, connected to, or otherwise in your system that looks like a serial port (maybe even a real serial port) that spits out a character or two into the system at boot time, confusing GRUB and stopping the normal boot process. The bad KVM I mentioned before was doing something like that, throwing a bogus keypress into the system at boot time.

@echknowbabble
All right, that's weird. Do you have any USB devices plugged into that host other than the keyboard or mouse and, if so, what are they? If you do, it might be possible that something reports itself as a type of HID connection and maybe the BIOS/UEFI in your system or GRUB is mistaking it for a keyboard. I know some UPS units could do that (though I've never seen it myself).

@echknowbabble said in GRUB waits for confirmation:

I have tried fresh installs of 8.2.1 and 8.3 and it will boot but not until I select an option from the GRUB menu. I am using UEFI without secure boot. There is an asterisk next to the 'XCP-NG" option which I believe confirms it is the default option, but GRUB will not start it until I manually select it.

Is your system connected to any sort of KVM switch? I had a weird problem where sometimes systems connected to a particular KVM switch would do this if they were rebooted when they weren't the system the KVM was set to view. It would never happen if they were rebooted while being viewed by the KVM, only if they weren't and not always then. The symptom you're describing sounds exactly the same as what happened to me.

Installed and seems to be working well on my test systems.

@duperrey, I suspected that was the case after seeing that message but wanted to make sure. Thanks!

@tormi said in XCP-ng 8.2 updates announcements and testing:

@effBerntsen Do you have XOSTOR on the pool?

Not yet, but was planning to add it to this test pool so thought I should downgrade beforehand. Does that particular patch only apply to systems with XOSTOR already installed?

@duperrey, that doesn't seem to work for me. I receive an error from yum:

No Match for available package: http-nbd-transfer-1.3.0-1.xcpng8.2.x86_64
Nothing to do