Veeam slow on new OS support

[aj_potc]

I just want to voice my support for @dejan.ilic @liu.se's suggestion.

Like others, I upgrade to the latest stable release from Red Hat very rapidly. If backups start failing on those hosts with no fallback option, it's a big problem.

[PTide]

@aj_potc, @dejan.ilic@liu.se,

Kindly contact our support team directly, describe the issue, and let them know that you would like to request a fix.
Once you do that, please post your case ID here.

Thanks!

[aj_potc]

I did find a pseudo-workaround to get Veeam going on a RHEL/CentOS system that's been updated to release 8.4.

It appears that veeamsnap cares only about the kernel version when it starts up, so if you choose to boot from the previous kernel (i.e., the latest kernel for the 8.3 minor release), then Veeam will run again.

This is not a very satisfactory workaround, as you have to manually select and use an older kernel, but it does allow backups to run even though other system packages have been updated to 8.4. In my mind, it's better than downgrading the OS.

[tsnyder]

RHEL/Oracle/CentOS 8.4 still isn't officially supported and we're almost 90 days after general availability. Just got a kickback from support due to an 'unsupported platform.'

I now get to make a choice between applying security updates and having backups under Veeam support.

Absolutely crazy.

[PTide]

v11a is just around the corner and will support RHEL 8.4. Until then the hotfix can be obtained from our support team (as usual).

Thanks!

[wishr]

Hi everyone,

Please specify your case ID if you've got a "kickback" from our technical support team, so we could analyze and prevent such situations from happening in the future.

Thanks

[aj_potc]

@wishr:

Sure thing. Here's an example for you:
#02394999

I don't know if that ticket is older than what you're expecting, but the ticket doesn't offer a workaround for the issue. (Perhaps one wasn't known at the time, but I'm bringing it up for you to check.)

Thanks.

[Gostev]

This ticket is almost 4 years old so it certainly cannot be related to RHEL 8.4

wishr asked to see a support case where a paying customer was refused the hotfix for RHEL 8.4 support recently. As this means there's some internal communication breakdown where support engineers are for some reason unaware about the important hotfix availability. And we would like to bring this situation to the support management for review.

[tsnyder]

Case # 04950261

[aj_potc]

This ticket is almost 4 years old so it certainly cannot be related to RHEL 8.4

Sorry, but I gave the wrong ID (I copied this one from the title of the ticket, but I'm not sure what it refers to).

Here's the correct one:
#04867185

[Gostev]

@tsnyder thanks, support management is looking into it.

@aj_potc this one is back from June, we certainly did not have a hotfix available back then yet...

[aj_potc]

Okay. So...I guess I asked too early? The ticket reply said that 90 days is the official timeline, and that support has no information about when a fix will be released (in other words, "don't bother asking"). So I didn't see any reason to keep the ticket open at that time.

Is there a notification system in place for such hotfixes, or would I just have to find out by chance?

[Gostev]

There's no notification system about hotfixes, only about releases. But hotfixes are also not meant for wide distribution anyway, because they are not tested as thoroughly as normal releases. Specifically, product releases get at least 2 weeks long full regression testing cycle to catch situation when changes and fixes unexpectedly break something elsewhere in the product (for example, some restore options stop working from otherwise good agent-based Linux backup).

Keeping a ticket open would actually be a really good solution, if our support allows this in such cases. Because whenever we have a new release, we always start its Early Availability phase by asking our support team to distribute it to whoever has support cases open on the issues this particular release solves.

[tsnyder]

I hate to pull on this thread even more but if we look at the Oracle Linux release dates (Oracle doesn't tag minor x.1 x.2 x.4 releases for EUS like RHEL) :
8.0 8.0 2019-07-18
8.1 8.1 2019-11-15
8.2 8.2 2020-05-06
8.3 8.3 2020-11-13
8.4 8.4 2021-05-26

This basically means that Veeam never 'supports' up-to-date Oracle Linux, and the amount of time that any version is supported is half of a given year.

You're taking at some points > 3 months to 'officially support' releases that occur every 6 months like clockwork.

I don't know of any other vendor that experiences this type of limitation.

[Gostev]

Sure, every vendor is different. We support a wide variety of Linux distributions (not to mention other OS, hypervisors, clouds and enterprise apps) and thus choose not to have our release schedule aligned to one particular Linux distribution. I can certainly see how a vendor that focuses on Oracle Linux specifically will be much faster and strictly aligned to its releases. Veeam was like that in our early days, when we only supported the single platform (VMware).

If timely support of semi-annual Oracle Linux releases is essential for you, then you should just switch from Veeam to a vendor that specializes on Oracle Linux, or at least just-Linux, as opposed to using an enterprise backup vendor like Veeam which has to juggle between continuous "like clockwork" releases of over a hundred of different platforms and applications, and dealing with how their happen to map minor and major release vehicles of our own platform.

While Veeam is the best option for classic enterprise IT shops who tend to use LTS versions to reduce the number upgrades they have to do, have strict rules of not jumping new releases until they are well proven in the field, etc. In other words, doing everything that helps to reduce costs and minimize production environment disruption.

In fact, it's not unusual for some of our largest customers to start the internal certification process of our new major releases only after we have the first minor release (like 10a or 11a) out. Meaning, they don't even start deploying new Veeam versions until after ~9 months since GA. But they follow the same pattern for most of the other software they are using, so there's never a rush to update Veeam to get some brand new platform version support either.

[PTide]

UPDATE: If your support engineer denies that the fix exists, please refer them to this KB article.

Thanks!