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.

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

@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

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

Seems to be working well on my test servers.

This seems to be working well for me too.

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

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

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

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

Seems to be working well on my test servers.

This seems to be working well for me too.

@Danp You're right, I missed the question mark on it when I tried it before. With the question mark, it works. Thank you for your help.

@Danp I've tried that and it doesn't seem to work. Entering hasVendorDevice into the filter box whether followed with nothing, with :true or :false, leaves the filtered VM list completely empty. I'm running on xoa updated to the latest stable channel version, 5.99.1.

I'm trying to filter the VM list to show only Windows servers that are set to receive drivers via Windows update and don't seem to be able to do it. As far as I know, the property is called hasVendorDevice but using either hasVendorDevice:true or hasVendorDevice:false ends up showing no VMs at all? Am I doing something wrong and, if so, what or is it just not possible to filter on this? I'm also trying to filter based on the secure boot setting and having the same problem with that.

Any help would be greatly appreciated.

@bleader They're installed and running well on my test lab systems.

@OhSoNoob I've used XOSTOR on top of MDRAID and it seemed to work well for me during my testing. I ran tests of it on top of MD RAID 1, 5, and 10 (MDRAID's "RAID 10" which isn't really RAID 10) and had good luck with it. The XOSTOR is really adding a second layer of redundancy at that point, similar to MDRAID 5+1 builds so is almost overkill. Almost.

Where I see the most benefit from XOSTOR on MDRAID would be on top of RAID 10 or RAID 0 arrays. Depending on the speed of your drives, you might get some benefit from the increased read speed (and read/write speed for RAID 0). In addition, RAID 10 would give you some additional redundancy so that losing a drive wouldn't mean the loss of that node for XOSTOR's purposes, possibly making recovery easier.

The ability for some redundancy might also be useful for a stretched cluster or some other situation where your network links between XOSTOR nodes isn't as fast as it should be; The ability to recover at the RAID level might be much faster than recovering or rebuilding an entire node over a slow link.

@ronan-a, I'm not sure if you remember, but the very first test of XOSTOR I ran, shortly after it was introduced,, were on top of RAID 10 arrays. I kept that test cluster alive and running until equipment failure (failed motherboards, nothing related to XOSTOR or MDRAID) forced me to scrap it. I had similar teething pains to others while XOSTOR was being developed and debugged during the test phase, but nothing related to running on top of MDRAID as far as I could tell.