V11 XFS Supported OS

[mkretzer]

Hello,

according to the digest V11 supports other OS for XFS repo. Debian 10, which is still using Kernel 4.19 is also supported.

Is there a performance difference?

Markus

[HannesK]

Hello Markus,
EDIT: we only tested the default kernel on Debian 10. We did not test 5.4 or newer

The reason for the 5.4 recommendation is https://blogs.oracle.com/linux/xfs-data ... ng-reflink

The conversion finished as of Linux 5.4.

So chances are there, that there is is a difference in performance.

Best regards,
Hannes

[mkretzer]

So that means you did test Debian 10 with backported kernels and this is an officialy supported variant for debian 10?

Can we switch from Ubuntu 20.04 to Debian 10 with 5.4 kernel without having to re-transfer the backups?

Markus

[HannesK]

Hello,
I re-worded my last post as it was not clear enough. Sorry for that.

Why do you want to switch? Do you see any issues with Debian 10?

We do not test such scenarios. But the filesystem is handling everything. Do the distribution itself must be irrelevant.

Best regards,
Hannes

[mkretzer]

Hannes,

we only use Ubuntu for the repo because Debian was not fully supported and it did not have the recommended kernel (5.4).

While the difference is not that big we use Debian for 99 % of our linux systems and as such would have liked to use a system we know best.

Markus

[Gostev]

Markus, I say it's a good idea you start with vanilla Debian 10. Then if you do run into any issues at your scale, upgrading kernel to version 5.4 or later will naturally be the first thing to try!

[UBX_Cloud_Steve]

FYI.. We use CentOS 8 with v10 and reflink support is working nice and fast.

[Regnor]

Will the support for XFS with SLES also include openSUSE? From my understanding both are compatible and differ in support/lifecycle.

[Gostev]

I know we agreed with our QC that they will not have openSUSE repositories in the their labs to keep the number of configurations manageable.

@PTide what do you think, how different SLES and openSUSE are? Because for example in case of RedHat/CentOS, we treat them as the same thing from support perspective, since they are identical (well, until the most recent developments with CentOS Stream that is).

[tsightler]

There are two openSUSE variants, Leap and Tumbleweed. My opinion is that these are roughly the equivalent of CentOS (at least before the recent announced CentOS Stream changes) and Fedora respectively. These days, openSUSE Leap is based on SLES and my understanding is that it now uses the same kernel and packaging as SLES, and follows the same basic support lifecycle. Based on this my gut says it should be OK to support it in the same way we've historicaly supported CentOS as a rebuild of RHEL, but @PTide may know something subtle that makes this not possible.

However, I think it's safe to say that we would not support openSUSE Tumbleweed.

[PTide]

From the technical perspective - I have never seen or heard of a user-space application that works on SLES but does not work on its openSUSE counterpart (kernel space is another story). I've asked some guys who might be able to add some comments on the subject (waiting for them to answer).

From the manageability point of view - I thought that modern Leap versions have an average length of life around 1.5 years (shorter than SLES), which presents us in front of a choice between 'stay on an EOL version' and 'upgrade to the version that is not supported by the application that I want to run'. I think that's another potential problem for those who are strict about what's running in their environment.

Overall, I agree with Tom - although Leap might be carrying more of bleeding-edge packages than SLES (the latter might use slightly older versions of the same packages for the sake of stability), I think that core stuff (such as filesystems) should be identical.

As for the Tumbleweed - I don't think that supporting a rolling release for an enterprise usage is a good idea in general.

Thanks!

[nitramd]

I installed Tumbleweed several months ago for testing purposes, I believe the kernel was 5.8x. Today, I see that the kernel is version is up to 5.10x, so this seems to reinforce @Ptide's and Mr. Sightler's perspectives on Tumbleweed.

I also thought that Leap's length of life was ~18 months but it turns out to be a bit different. Major Leap releases are supported for ~36 months while minor releases are roughly 12 months. More information here: https://en.opensuse.org/Lifetime

Given openSuse's Leap release cycle, I'm curious to know how this would impact Veeam's strategy.

[tsightler]

Leap has been through a few changes over the years, but with the release of Leap 15 I believe it now tracks SLES almost exactly and has a similar lifecycle, very much like how CentOS has historically tracked RHEL. It's even fully supported to convert from Leap to SLES at any time so there can't be a major difference between them and, for example, Leap 15.1 uses the same kernel as SLES 15.1 and has basically the same lifecycle.

SLES 15.1 was released on Jun 24, 2019 and is supported until Jan 31, 2021
Leap 15.1 was released on May 22, 2019 and is supported until Jan 31, 2021

SLES 15.2 was released on Jul 21, 2020 and is supported until at least 6 months after SLES 15.3 is released
Leap 15.2 was released on Jul 2, 2020 and is supported until at least Dec 2021 (6 months after Leap 15.3 is released)

So, these days, SLES and Leap are basically the same, using the same kernel and library versions, etc., but this hasn't always been the case.

The major different between SLES and Leap are of course, like any "community" Linux, there's no support commitment from the vendor, also, the Leap package repositories include a significant number of "community supported" packages that aren't part of SLES, and the final major difference is that the major version is only supported for 3-4 years, basically, until the next major version is released, while for SLES previous major versions continue to be supported for as long as 10 years. Basically, once a new major version is released the prior version is supported only for about 6 months of overlap.

I'll investigate a little more the differences between SLES 15 and Leap 15 to make sure my statements above are accurate and will continue to discuss internally.

[Regnor]

Thanks for all your replies and research.
I'm neither a Linux nor openSUSE expert, so can't offer much help here.
I would also only focus on Leap and not on tumbleweed as it's their rolling release (and the future of CentOS~Stream).

From what I read is that SUSE and openSUSE are working to make both distributions more closer and to share the code base.
https://en.opensuse.org/Portal:Jump
https://news.opensuse.org/tag/jump/
So Leap 15.3 could be even more compatible then it's at the moment.

They also think about moving at the spot which CentOS left open so perhaps we'll see a different support lifecycle in the next time.

I'm not sure how disrupting upgrades to the next Leap release are; as SLES calls them servicepacks I would think it's a big jump.
The question is should one rather use the major releases or is it recommended to update to each minor release?

[evilaedmin]

@PTide what do you think, how different SLES and openSUSE are? Because for example in case of RedHat/CentOS, we treat them as the same thing from support perspective, since they are identical (well, until the most recent developments with CentOS Stream that is).

Does this apply to Oracle Linux as a downstream rebuild also? We've successfully converted our RHEL and CentOS instances and are trying out the "unbreakable" kernel in some cases.

[Gostev]

No, as I recall us having some issues that were specific to Oracle Linux, but did not exist in RHEL/CentOS. Presumably because there are some significant changes to make the kernel "unbreakable"?

[Regnor]

I also thought that Leap's length of life was ~18 months but it turns out to be a bit different. Major Leap releases are supported for ~36 months while minor releases are roughly 12 months. More information here: https://en.opensuse.org/Lifetime

The statement from openSUSE is a bit misleading. The lifecycle of a major release (15.0 to 15.X) is about 3 years, but each single release(15.0;15.1;15.2;...) is only maintained for 18 months. So you still need to upgrade to each minor version in order to stay supported and receive updates. openSUSE 15.0 is EoL since Dec 3rd 2019.

@all: With my minor linux skills I was able to upgrade from 15.1 to 15.2 in about 30 minutes and didn't have any problems afterwards (webserver+mariaDB).
Of course that's not a production system (homeserver) and rather small, but on the other hand a Veeam repository server should have much less dependencies and therefore less possible failures?

[HannesK]

Hello,
just to remind you: all Linux distributions have XFS support even today (experimental support https://www.veeam.com/kb2976 ). With V10 we only had full support for Ubuntu.

Customers were using different distributions, too.

We had zero support cases related to XFS block cloning integration so far, for any distributions.

Especially for home-environments, you can use whatever you like.

Best regards,
Hannes

[Regnor]

Hi Hannes,

in a lab of course it wouldn't matter that much, but in production I would only use what's officially supported by Veeam.
But thinking about it; if the XFS repo is critical, one could probably also afford the subscription for RHEL/SLES.
And looing at Red Hat; they're offering free licenses for RHEL:
https://www.redhat.com/en/blog/new-year ... okmark%201

Anyway, the stability of XFS sounds promising, also compared to what problems ReFS had so far.

[doum]

Do we have the full list of supported distributions in v11 ?

We are currently changing our veeam repository servers.
I'm thinking about moving from Win/ReFS to Linux/XFS, but we don't use Ubuntu here, only RedHat or CentOS

I have no problem using an experimental features some months waiting for v11 but I would like to know if CentOS (or a fork now ) or Redhat will be officially supported in V11

thanks

[Gostev]

RedHat will be supported for sure, and CentOS too (but only versions before the change).

[doum]

thanks a lot Gostev for this really quick answer

[soehl]

RedHat will be supported for sure, and CentOS too (but only versions before the change).

This means no CentOS 8 Stream, right?!

[Gostev]

Not in v11 for sure. We may tweak the list of supported distributions down the road, as their market share changes. But based on QC costs considerations, we can only support a limited number of most popular Linux distributions, so let's say top 3-4 which collectively represent over 90% of all Linux deployments in the world. RedHat used to be equal CentOS before so this went as a single distro for us, but CentOS Stream changes the game.

[no-reply]

CentOS wasn't equal to RHEL in most deployments:
https://community.theforeman.org/t/cent ... ined/21692

[tsightler]

Perhaps not equal, but substantially closer than what CentOS Stream is likely to be going forward (I also don't agree with at least some of what is written in that post regarding how CentOS upgrades between point versions work, but I guess it's not really important).

The bigger issue is that, previously, CentOS was built from RHEL sources, and it strived to be as compatible as possible. Of course it was not 100% identical, but at least a CentOS system and RHEL system of the same version could be mostly assured to have the same library versions, same kernel base versions, etc. The chances of compatibility were very high, and, if, for example, testing of RHEL 8.3 broke something, it was very likely it would also be broken in CentOS 8.3 and, since CentOS was the lagging distro, usually by the time CentOS was shipping any 8.3 packages, any issues with those packages were already addressed due to the testing with RHEL 8.3

With CentOS Stream this is flipped on its head. RHEL is the lagging distro so testing on RHEL no longer provides any significant insight into the likely compatibility with CentOS Stream and, what is more challenging, testing CentOS Stream today provides limited insight into whether there are any issues with the current RHEL version, or even CentOS Stream tomorrow. Effectively, CentOS was previously a derivative distro, based on the same package/kernel version as the RHEL parent. Now, CentOS is a different distro completely, halfway through the release cycle it could very likely have completely different package versions than the current shipping RHEL version which just did not happen with RHEL/CentOS. It's going to be very difficult for a 3rd party vendor to support that since they are willing to change package the included package versions at any times, rather than just at point releases, since there are no point releases.

[Regnor]

@Tom: Did you have a chance to discuss openSUSE internal? I'm asking because according the the V12 System requirements topic then plans are to remove the support for openSUSE.
Yesterday Leap 15.3 has been released which is now built on the same binary packages like SLES. The only downside I see is the lifecycle of about 12-18 months, which means a bit more administrative overhead and staying on the top of the edge.
From my understanding, you (Veeam) would only need to check compatibility/support for SLES, just like you needed to do with CentOS?

[tsightler]

@Regnor I got sidetracked on the way when I lost access to my SuSE account and couldn't get updates for my lab SLES installs. By the time I managed to get my access back I guess I had let this slip off my radar. I'll take another look at SLES vs Leap 15 over the next couple of days and see how similar they are. In general, I agree with you that it should be like the SLES/CentOS case, but I wanted to confirm myself just how close they are before trying to convince QA of that!

[Regnor]

Thank you very much in forward for your effort; looking forward to your results

[tsightler]

I've completed my initial research and I'd have to say, from my personal perspective, that I don't see why we can't treat SLES and OpenSuSE Leap as effectively equivalent distros, starting with Leap 15.3 at least. Before that point there were some minor differences and it was really difficult to tell if they were identical or not as they used different build systems with different minor versions, etc, but starting with Leap 15.3, the bulk of the packages are even the exact same binary as SLES, even still signed with the SLES signing key, which is an even tighter relationship than RHEL/CentOS ever had.

I have to say that SuSE has really upped the game with Leap 15.3 by providing a rock solid, enterprise level distro that is available for free. Sure, it has a shorter lifecycle for minor releases, but that seems OK to me for a completely free product. Also, it's super easy to officially convert a Leap 15.3 system directly to SLES without a reinstall, which is pretty nice as well.

Now I just have to convince QA if the above!