Best posts made by JeffBerntsen

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

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

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

@stormi

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

Seems to be working fine for me as well.

@stormi So far, so good for my systems with the re-updated kernel.

@stormi No regressions so far on my test pool with both sets of test updates installed.

@stormi Updated my 8.0 test server and all seems to be working just fine so far.

@stormi Yup, I did just before trying to install the test update so I must have gotten it after you published. Everything seems to be working fine here afterward.

@ronan-a said in Updates announcements and testing:

@JeffBerntsen I think I will release a new linstor RPM to override the sm testing package. The current is: sm-2.30.7-1.2.0.linstor.1.xcpng8.2.x86_64.rpm. For the moment, you can downgrade if you want.

That seems to have taken care of it. Left all upgraded versions from this thread in place except for sm and sm-rawhba which have been downgraded to the linstor versions from the regular repo. All seems to be working well now.

@olivierlambert said in Updates announcements and testing:

If you test XOSTOR, don't test other updates, because this might break the rest.

Also, never switch the master after updates, the master HAS to reboot first, whatever happens.

I know that XOSTOR might break during an update test. I thought whether it did or didn't might be something you would be interested in as part of testing and that's part of why I test with it in place and running.

@olivierlambert said in Updates announcements and testing:

Adding @ronan-a in the loop.

When you said "break", can you be more specific @JeffBerntsen ?

@olivierlambert said in Updates announcements and testing:

Hmm no reason for that, did you have other updates coming with it? (ie replacing some other unrelated packages).

I have 3 servers in my lab's test pool, vh97, vh98, and vh99. Server vh97 was the pool master. I placed it into maintenance mode and shifted the pool master to vh98 in the process, installed the updates, and rebooted.

When vh97 came back up, it could no longer attach to the XOSTOR SR. Attempting to replug the PBD gives me errors indicating that vh97 can no longer see the SR. It appears that there are some related errors in the SMlog file (I've captured a copy for future examination).

The updates installed were only the ones from this most recent set. All of the other test updates from this thread from the last two weeks were already installed and running without problems on all 3 servers in the pool.

@stormi
This seems to be working well on my test pool.

@stormi Seems to be working well for me too.

@stormi Some quick testing of the alternate kernel on my test systems seems to be working fine with the not-unexpected issue that the XOSTOR test does not come up and run on it.

@stormi Thanks, I'll give the test script a try on my test Alpine installation and see if it works for me.

My OpenSUSE Leap 15.3 installation works just fine via secure boot with one warning/error message at boot. It's complaining that it can't generate a temporary hibernation key because of a missing EFI_RNG_PROTOCOL. Except for that, it works great under secure boot. If not being able to have hibernation support in the VM's operating system is the only issue, that's definitely minor and something I don't use and won't miss.

EDIT: I'm also going to try a fresh installation of Alpine into a VM set for secure boot and see how that works out. My test was trying to convert an existing VM that was successfully booting under UEFI without secure boot enabled.

EDIT 2: I've managed to get Alpine working as well. It appears that their Wiki entry on setting up secure boot isn't quite right yet. They have a utility which generates keys and creates a signed unified boot image. My best guess is that there is some problem with the signature on the boot image. I was able to get things working by enrolling the generated auth files for the VM uuid on the host system then booting the VM with secure boot disabled and using the sbsign utility to sign the boot image with the generated db key and certificate. It adds a second signature to the boot image which appears to be identical to the first one. Switching to secure boot mode and rebooting works on the re-signed boot image.

@stormi
Working well for me so far.

@stormi Running well for me. I've tested startup, shutdown, and migration of Windows and Linux VMs with no obvious regressions.

@stormi
I'll use this one to test the 8.2-to-8.2 upgrade we talked about on the software RAID thread.