-
- Service Provider
- Posts: 96
- Liked: 27 times
- Joined: Feb 09, 2019 5:06 pm
- Contact:
Re: Our known v12.1 problems in a large Hyper-V environment
Please lets not go into the product downloads, I downloaded VBR/VAW/VAL more than I have clients - even for free edition, and vice versa, when patching via VCSP, you lose the count because we only apply patch once. Do a metric support cases/active licenses (not including NFR, and promo licenses).
As for documentation, I am still awaiting a response from a technical writers from a year ago, regarding the gMSA + SPNs scenario, which in my latest case engineer thought is the main culprit.
As for documentation, I am still awaiting a response from a technical writers from a year ago, regarding the gMSA + SPNs scenario, which in my latest case engineer thought is the main culprit.
-
- Chief Product Officer
- Posts: 31960
- Liked: 7436 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Our known v12.1 problems in a large Hyper-V environment
Sorry but this objection doesn't hold any ground. We see it clearly from our big data that the product download and patching behavior remains largely unchanged over years across our entire customer base, just as you would expect. Thus, it can be removed from consideration as a constant when looking at the above-mentioned metric over multiple years/releases.
Obviously, everyone just keeps doing what they have always been doing as it comes to how often they download, or how many times they download the same release (for most, the number of repeat downloads equals to the number of remote sites). I mean, why would you personally start doing a few times more VBR downloads suddenly than you needed in all the previous years? Of course it's about the same drill for you every release?
In any case, we look at both total and deduplicated number of downloads, and I can tell you this does change the trend at all, which shows significant quality improvement with each release. Besides, it's not the only quality metric we use. It was just a most obvious example of what types of objective metrics we're monitoring.
You have a point about newly added patching with VCSP changing the field, however it does not help your argument either as VCSP-based patching can only impact this metric negatively because a single download now patches dozens of product installations, each of which can then potentially have a support issue.
Obviously, everyone just keeps doing what they have always been doing as it comes to how often they download, or how many times they download the same release (for most, the number of repeat downloads equals to the number of remote sites). I mean, why would you personally start doing a few times more VBR downloads suddenly than you needed in all the previous years? Of course it's about the same drill for you every release?
In any case, we look at both total and deduplicated number of downloads, and I can tell you this does change the trend at all, which shows significant quality improvement with each release. Besides, it's not the only quality metric we use. It was just a most obvious example of what types of objective metrics we're monitoring.
You have a point about newly added patching with VCSP changing the field, however it does not help your argument either as VCSP-based patching can only impact this metric negatively because a single download now patches dozens of product installations, each of which can then potentially have a support issue.
-
- Service Provider
- Posts: 192
- Liked: 38 times
- Joined: Oct 28, 2019 7:10 pm
- Full Name: Rob Miller
- Contact:
Re: Our known v12.1 problems in a large Hyper-V environment
This sounds like the same situation I've been dealing with for the last 2-3 months.jotge wrote: ↑May 03, 2024 12:29 pm After upgrading our environment to Veeam v12.1, we have the following problems that did not occur before:
- A single backup job starts sporadically without any processing taking place. However, the process consumes a lot of CPU resources on the backup server (case # 07248027)
The high utilization is also noticeable when operating the backup server. The backup job must be stopped manually in the Windows Process Manager, it cannot be stopped in the VBR Console. These are different jobs, it is not always the same one.
microsoft-hyper-v-f25/jobs-stuck-pendin ... 93367.html
My current case for this issue is: 07306709
-
- Service Provider
- Posts: 96
- Liked: 27 times
- Joined: Feb 09, 2019 5:06 pm
- Contact:
Re: Our known v12.1 problems in a large Hyper-V environment
Yes it is related to the 12.1. Continues to latest version. We provided a lot of logs and the support case is still going
-
- Enthusiast
- Posts: 28
- Liked: 4 times
- Joined: May 20, 2019 11:44 am
- Full Name: Jan Groschopp
- Location: Deutschland
- Contact:
Re: Our known v12.1 problems in a large Hyper-V environment
Update A single backup job starts sporadically without any processing taking place. However, the process consumes a lot of CPU resources on the backup server (case # 07248027)
@RobMiller86
The last recommendation from Veeam Support was to check and set the AV exceptions. I did this in a time-consuming - as there are a lot of servers - process and today I found another Hyper-V backup job that had been "hanging" for two days. I am currently collecting dumps and logs to send to support. I am curious how it will continue.
@RobMiller86
Yes, it appears to be the exact same problem.This sounds like the same situation I've been dealing with for the last 2-3 months.
The last recommendation from Veeam Support was to check and set the AV exceptions. I did this in a time-consuming - as there are a lot of servers - process and today I found another Hyper-V backup job that had been "hanging" for two days. I am currently collecting dumps and logs to send to support. I am curious how it will continue.
-
- Service Provider
- Posts: 96
- Liked: 27 times
- Joined: Feb 09, 2019 5:06 pm
- Contact:
Re: Our known v12.1 problems in a large Hyper-V environment
Have you recieved private fix already? Mention my case nr. However we ran into issues with wmi queries being out of memory. Looks like veeam changed something regarding wmi commands that does fit into the wmi allocated memory and the process gets killed on windows server side. Veeam has no way of checking whether the command returned something and waits, and waits, and waits...indefinitely.
-
- Enthusiast
- Posts: 28
- Liked: 4 times
- Joined: May 20, 2019 11:44 am
- Full Name: Jan Groschopp
- Location: Deutschland
- Contact:
Re: Our known v12.1 problems in a large Hyper-V environment
Yes, for case # 07248027 we are testing a private fix from today. I'm looking forward to the results.
Who is online
Users browsing this forum: Google [Bot] and 25 guests