Posts made by ravenet

@stormi No issues so far on Ryzen 1700x, Xeon e5-2640v3, and 2 Epyc 7313P systems

Reminder, Centos 7 EOL 1 year away

https://www.phoronix.com/news/CentOS-EOL-2023-7-Stream-8

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

@mauzilla Use core, it's more dedicated to just being a NAS.
Scale has kvm hypervisor and pod management features which would add unnecessary overhead when you just want NFS storage repository.

Pool is resource pool, yes.

pool can consist of multiple hosts which can live migrate VMs

Server = host

@fred974
The decision on where you install Racher is up to you. You can first try a separate VM with docker, or even test using the beta xcp docker runx piece, then do a basic rancher in docker for testing, but this obviously has some redundancy/resiliency HA limits. if it breaks you end up with no access or failover and loss of data or even ability to manage your kube cluster depending on how you setup docker volumes etc. Is good to test and get familiar. You should technically be installing rancher in kubernetes, but in a dedicated management cluster.

Honestly for home lab, docker is fine, as is tossing it in your kubernetes cluster if already setup, just mind your backups and figure out volumes so you can recover if goes kaboom.

Here's a rancher best practices for you, though obviously meant for large corporate and cloud rollouts.

https://www.suse.com/support/kb/doc/?id=000020105

@gduperrey Seems fine here as well under basic usage.

For managing your kubernetes, I'd look closely at installing Rancher

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

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

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