Posts made by JeffBerntsen

@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

Both sets of updates installed and tested in my lab with no problems so far.

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

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

@ronan-a said in Updates announcements and testing:

@JeffBerntsen What's your sm version? I suppose, you updated your hosts and you don't have the right one.

Please send me the output of: rpm -qa | grep sm-.

Definitely possible although it appears they were updated as part of installing the previous updates in this thread from the past couple of weeks.

What I have is:

sm-cli-0.23.0-6.xcpng8.2.x86_64
sm-rawhba-2.30.7-1.3.xcpng8.2.x86_64
sm-2.30.7-1.3.xcpng8.2.x86_64

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

@gduperrey This update breaks the XOSTOR setup in my test lab. Would you like any information from me for troubleshooting? If not, what's the easiest way to revert the test updates?

Seems to be working fine for me as well.

@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 That worked to get the auth files generated using Alpine's instructions enrolled as far as I can tell but switching the VM to secure boot after that still fails, dropping me into a UEFI shell. Alpine 3.15 is the first version with secure boot support and it's possible there are still some glitches there.

Instead of that, I'm now trying to set up a secure boot with a fresh install of OpenSUSE leap 15.3 which I know does support secure boot and will see if that works out.

@stormi

Testing UEFI VMs. So far working fine without secure boot. Having a problem with secure boot under Alpine Linux. They don't use MS certificates and a shim as a lot of distros do but instead have you generate a set of keys for your installation and then enroll them. It looks like this is a problem with enrolling the generated keys in the TianoCore boot firmware. I'll try with a different distro and see if it's any better with something different.

@stormi said in XCP-ng 8.2.1 (maintenance update) - ready for testing:

@jeffberntsen probably not. We'll need to rebuild some packages, like sm on top of the latest versions else you will lose needed specific patches that are not merged in the main branch yet.

CC @ronan-a

That's what I thought but figured it wouldn't hurt to ask.

@stormi
Is it safe to install this on a machine where I'm already testing XOSTOR?

@danp said in CH8.2.1:

Found this -- https://support.citrix.com/article/CTX335564

Yes, that's how I found it as well. It's still not up on their blog as of this morning. I wonder if that's intentional.