Rocky Linux now GA. Veeam support ??? (also AlmaLinux)

[HannesK]

it's off-topic, but RHEL 9.2 is supported since some time for Veeam Agent for Linux

For VMware proxy: let me check, that might be a documentation glitch. Thanks for bringing it up!

[mikeely]

Yes, but how about Rocky/Alma?

[HannesK]

the answers of my colleagues above apply for Rocky / Alma

[lukklin]

Will there be any change in terms of V12.1?

[rovshan.pashayev]

Hello Lukas,

Rocky Linux and AlmaLinux won't be on the support list for V12.1.

Rovshan.

[lukklin]

Hi Rovshan,

thanks for the update..

Lukas

[mikeely]

Rovshan, how about 12.2? Folks are clamoring for it - I'm getting my ear bent because of this at least once a week.

[Gostev]

Actually, we should not need a release at all for something that already works (presumably).

Only need QC to verify this, and update System Requirements and Limitations.

In theory, QC can be done in the next few weeks now that QA has been released from 12.1?

[aj_potc]

Veeam has been working fine for me on Rocky for the past couple of years.

It would make a lot of people very happy to get official Rocky/Alma support!

[jeffshead]

Does the veeamsnap module's loader still expect to see "rhel" as the ID field in the /etc/os-release file? Do you still have to modify that file on an AlmaLinux and/or Rocky server?

[aj_potc]

Does the veeamsnap module's loader still expect to see "rhel" as the ID field in the /etc/os-release file?

Yes, it looks for "rhel" in this file.

Do you still have to modify that file on an AlmaLinux and/or Rocky server?

I prefer not to modify system files, so instead modify the veeamsnap startup script, /usr/sbin/veeamsnap-loader.

Find the following line in that file:

Code: Select all

if not distName in ["oracle", "ol", "redhat", "rhel", "centos"]:

Add your distro's name to it. For example, for Rocky:

Code: Select all

if not distName in ["oracle", "ol", "redhat", "rhel", "centos", "rocky"]:

This has to be done every time you upgrade the Veeam for Linux agent.

[johnnytan]

Hi Veeam,

I would like to request for the support for Veeam Management Agent for both Rocky Linux and Alma Linux Operating System.
Since the March 2021 (for Alma Linux) and June 2021 (for Rocky Linux) when both of them are released on version 8, many of our tenant are moving from CentOS 7 to Rocky Linux or Alma Linux. Since then, we have a lot of struggle to help our tenant to protect their data. At times, we have to resort to the traditional rsync to another server just to make sure their data are not lost in anyway.

2 years passed and Veeam Agent are still "barely" supported on both platform. Veeam Management Agent are nowhere to be seen and it makes us as a MSP, hard to convince them to stay on the Veeam platform.

Of course the fastest way to solve this is to make them stay on a VMware Platform, and make backup from there but I would rather them spend more money on backup and protecting their data loss than on the operating system platform itself.

Many thanks in advance for reading my request above.

[rovshan.pashayev]

Hello Johnny,

We've relocated your question to this topic, where discussions about Rocky and Alma Linux are taking place.

Thanks,
Rovshan.

[johnnytan]

Hi Rovshan,

Thanks, looks like there's no progress at all for both Veeam Agent and Veeam Management Agent.
While the backup are supported using a workaround, Veeam Management Agent are yet to be supported.

Any timeline we can expect this to be supported in the future?

[rovshan.pashayev]

Hello Johnny,

Internal negotiations are ongoing, and we don't have a specific timeframe. Stay tuned for updates as we work through the details.

Thanks,
Rovshan.

[je1000]

+1 for Alma. By now it’s has a big market share and it makes no sense for veeam not to support it.

[Gostev]

We've reached an agreement with QA to add both Rocky and Alma to their auto-tests and go from there depending on the results. Needless to say, these auto-tests is just a part of the story aka "smoke test", and more thorough testing will be required too before we can support these officially.

We already know that some product changes will be needed to support these distributions by the Agent Management functionality, which means we will only be able to ship this as a part of an update. However, if all is well with Standalone agents, then hopefully we will be able to declare official support for those without waiting for the next product update.

[mikeely]

Great news, Gostev. Long overdue but no less welcome for the wait!

[aj_potc]

Thanks very much for great news, Anton!

Please do keep us up to date on the progress.

[k00laid]

So to be clear there is not support today (1/24/2024) for Rocky/Alma Linux for a VSPC managed version of support but that is anticipated soon?

[Gostev]

They are definitely not officially supported today - only the specific distributions and their versions documented in the System Requirements are supported. Future state is TBD based on QA findings (see my previous post).

[VAXman65]

I too am modifying veeamsnap-loader, but instead of referencing the distName, I use the distribution family. This has the benefit of knocking out all options at once:

Code: Select all

# diff -u /usr/sbin/veeamsnap-loader.AS_SHIPPED2 /usr/sbin/veeamsnap-loader
--- /usr/sbin/veeamsnap-loader.AS_SHIPPED2      2023-11-21 14:06:41.000000000 -0500
+++ /usr/sbin/veeamsnap-loader  2023-12-06 19:01:29.000000000 -0500
@@ -261,7 +261,7 @@
                 key = key.strip()
                 val = val.strip()
                 d[key] = val
-    return d["ID"].strip("\""), d["VERSION_ID"].strip("\"")
+    return d["ID_LIKE"].strip("\""), d["VERSION_ID"].strip("\"")

 def Usage():
     usageText = "Usage:\n"
@@ -302,11 +302,11 @@
         if (platform.system() != "Linux"):
             raise RuntimeError("Found unsupported platform [{0}]".format(platform.system()) )

-        distName, distVersion = dist_os_release();
+        distFamily, distVersion = dist_os_release();
         unameKernelVersion = platform.uname()[2]

-        if not distName in ["oracle", "ol", "redhat", "rhel", "centos"]:
-            raise RuntimeError("Found unsupported distribution [{0}]".format(distName) )
+        if not "rhel" in distFamily:
+            raise RuntimeError("Found unsupported distribution family [{0}]".format(distFamily) )

         distVersionWords = distVersion.split(".")
         if distVersionWords[0] < "6":

[caioramos]

So to be clear there is not support today (1/24/2024) for Rocky/Alma Linux for a VSPC managed version of support but that is anticipated soon?

Hello, I would also like this information, we have many customers with AlmaLinux where we are unable to install the VSPC Management Agent.

[praveen.sharma]

Hi Team, Any update on ALMA Linux support?

[Gostev]

Last I heard it looks good for 12.1.2

[aj_potc]

That's amazing news! Thank you, Anton and the QA team, for listening to your clients and addressing this need.

I can't wait for my systems to be officially supported after a very long break!

[Vitaliy S.]

Hello, I would also like this information, we have many customers with AlmaLinux where we are unable to install the VSPC Management Agent.

It also looks good for us in the next minor update of the Veeam Service Provider Console (v8.1), scheduled to be released later this year.

[Gostev]

This might be a useful data point for planning purposes for those who are still choosing between Rocky and Alma for the long term.

As I shared at the beginning of this thread, we've been closely monitoring adoption of Rocky and Alma in the past years, and by now it is clear that Rocky is pulling ahead as the winner by a mile: already double of Alma and growing exponentially lately vs. linearly for Alma.

Based on this and a few other considerations, we've made the decision to put our own bets on Rocky for any future Veeam projects that will require a no-cost RHEL-compatible distro. This decision does not change our previously announced plans to support Alma too, as it still exhibits a healthy growth. However, we ourselves will be using Rocky.

We plan to balance our QA load from the addition of these two distros by dropping support for CentOS and Fedora with the next major release (2025).