@steff22
Far as I know, SVM, IOMMU, SR-IOV and POSSIBLY resize bar were enabled.
Can't check the threadripper system until the weekend as it runs production loads.
I'll reboot one of the Ryzen boxes tonight to verify what I enabled there, but was basically defaults other than making sure the 3 or 4 items above were enabled.
I have gpu pcie passthrough working on Asrock rack wrx80d8-2t (Threadripper), and x470d4u2 (Ryzen) to passthrough multiple Radeon Pro 7000 series gpus
Rodney
@stormi
Updated ryzen 1700 late last week, and Threadripper 5975 and Epyc 7313p servers. No issues so far.
Installing fresh on epyc 9224 this week
@Andrew Yes 8.3 will be xen 4.17. They've stated that this will be moved out of lab into the 8.3 official branch once they are happy with their and our feedback.
@Andrew said in XCP-ng 8.3 beta 
:
@ravenet I did not have any problems with my Mellanox Connect-4 Lx card during upgrades from 8.2.1 (5.0 driver), to 8.3 (5.4 driver), then update to current 8.3 (5.9 driver), and then update to Xen 4.17.3. My card has the 14.32.1010 firmware. It is not used for the management interface. It is used by VMs and continued to keep the same ethernet name and function for the VMs.
Thanks for testing
I finally got around to updating the firmware on this Mellanox connectx-4 LX adapter. Bit of jumping through hoops to install tools, find proper firmware, but went from FW version14.18.1000 to New FW version: 14.32.1010. Had to do an emergency network reset again, but it's back.
Obviously an incompatibility with the new 5.9 driver with much older mellanox firmware.
@olivierlambert said in XCP-ng 8.3 beta :
Thanks for your feedback @ravenet !
ill do firther testing later, in case issue is out-of-date firmware on the adapter itself being incompatible with the new driver. ill try and check the mellanox 5.9 changelog for firmware version requirements.
This update broke my mellanox network drivers for connectx-4 / 4 LX
Seems this latest patches included update from mennalox-mlnxen 5.4 to 5.9
I have no networking, and after an emergency network reset, eth0 and eth1 disappeared.
update1: used yum downgrade mellanox-mlnxen-5.4_1.0.3.0-4.xcpng8.3.x86_64
this didn't fix until I did another emergency network reset.
Looks like I'm back up and running.
Anyone else able to confirm this bug or am I alone in this hiccup?
I've done initial testing on Suse SLES/OpenSuse 15.4, 15.5 and the similar opensuse MicroOS 5.5
Installs, runs, reports correct information and stats so far. Basic commands work as expected.
@stormi No issues so far on Ryzen 1700x, Xeon e5-2640v3, and 2 Epyc 7313P systems
@stormi
Here's a Ryzen 1700 on Asus TUF B550
Combined test results:
test-hvm32-selftest SUCCESS
test-hvm32pae-selftest SUCCESS
test-hvm32pse-selftest SUCCESS
test-hvm64-selftest SUCCESS
test-pv64-selftest SUCCESS
Combined test results:
test-pv64-cpuid-faulting SKIP
test-hvm32-umip SKIP
test-hvm64-umip SKIP
test-pv64-xsa-167 SKIP
test-pv64-xsa-182 SKIP
3
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
0
@stormi Here's results from one of my lab servers. I'll run on some newer hardware next week.
Asus KGPE-D16, Opteron 6328, 128GB ram.
Combined test results:
test-hvm32-selftest SUCCESS
test-hvm32pae-selftest SUCCESS
test-hvm32pse-selftest SUCCESS
test-hvm64-selftest SUCCESS
test-pv64-selftest SUCCESS
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
3
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
0
@cbaguzman Watchdog client service talks to ipmi module on hardware, or service on vm host if running virtualized, providing a heartbeat. If the heartbeat isn't received by the host, then a power cycle is initiated. In xen this would likely be via a xe vm-reset-powerstate command, but I haven't looked at the documentation
In short, watchdog works by host or hardware listening for the heartbeat, then hits a hard reset if doesn't hear it. All the guest does is send heartbeats to host watchdog server,
You can't expect your host to reboot itself if it's locked up, that's the point of it.
So far fine on an epyc 7002 and a xeon e5 v3
@parallax I'd assume so. You'd just have that combustion iso provided as a disk image with each to provide the initial setup. I've not looked at custom template creation in XO
Otherwise you'd be looking at pxe and tftp, or better, use opensuse build services with kiwiNG to customize your own appliance with preconfigured settings etc.
@Louis said in Updates announcements and testing:
I am completely lost in relation to the way new software or updates are released.
- If I download the actual file, I get exactly the same file as I used to get for months
- there is an 8.2.1 which is not visual in the release overview
- I would have expect that an update has the name 8.2.2 ........
So, I am lost .....
This is not a major release triggering a dot version update. This is a set of patches.
yum update
Provide combustion via an iso mounted. Idea behind combustion/ignition is a usb plugged in, or pass through a usb if you already created one.
follow instructions on building the combustion file, drop in a folder named combustion. use whatever tool you want to move this folder into an iso, and label the iso itself combustion. Basically same steps as creating the combustion usb.
https://en.opensuse.org/SDB:K3s_cluster_deployment_on_MicroOS
Am testing ext4-ng and noted that the vdi's it creates are not matching their uuid on filesystem. If I look at the ext4 file structure itself they are simply labeled 1, 2, 3 etc.
-Good news is I could create a 3TB vdi on this sr within xoa without having to use the command to force it as raw
I tried a raw-device sr but still get error that driver not recognized. Assuming plugin still not in
@nasheayahu
You can script mount and umount commands as part of jobs or as part of backup jobs.