So far fine on an epyc 7002 and a xeon e5 v3

SLES 12.5 (usual warnings of sles12 xe-guest-utilities-xenstore conflicts with SUSE xen-tools)
IP addresses reporting : OK
Management agent detected : OK
Clean shutdown/reboot : OK

SLES 15.1 seems fine
IP addresses reporting : OK
Management agent detected : OK
Clean shutdown/reboot : OK

OpenSUSE LEAP 15.2 - Failed to determine Linux distribution and version

@gduperrey Seems fine here as well under basic usage.

@JustinTimperio I can test SLES for you, I'm a SUSE partner so have access. Here's output from a sles11.4,12.4, 12.5, 15 and 15.1. Sorry don't have a sles15.2 spun up (only leap15.2) but easy enough to extrapolate.
Best way to get stuff into their official distro is to have it build on OBS

NAME="SLES"
VERSION="11.4"
VERSION_ID="11.4"
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:11:4"

NAME="SLES"
VERSION="12-SP4"
VERSION_ID="12.4"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:12:sp4"

NAME="SLES"
VERSION="12-SP5"
VERSION_ID="12.5"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP5"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:12:sp5"

NAME="SLES"
VERSION="15"
VERSION_ID="15"
PRETTY_NAME="SUSE Linux Enterprise Server 15"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15"

NAME="SLES"
VERSION="15-SP1"
VERSION_ID="15.1"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP1"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp1"

@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

I see movement in the github repo again. Good sign!

@olivierlambert @ronan-a Has there been any update on this development? I do see an update to master in org.xen.xapi.storage.raw-device from feb 2020. is it more safe to test now?

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

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

@nasheayahu
You can script mount and umount commands as part of jobs or as part of backup jobs.

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

@ganeshb
https://xcp-ng.org/blog/2021/09/14/runx-next-generation-secured-containers/