Setting up Veeam to skip a VM when a snapshot already exists

[jcm7770]

[FEATURE REQUEST - add option to skip replication on a VM when sees that a Snapshot already exists for that VM.]

When a Veeam job starts and the job begins replicating a VM that already has an existing snapshot, the VM stops responding during the attempted snapshot creation and continues to not respond for at least two hours after the replication fails on that VM, causing downtime for users trying to access that VM. This only happens if there is another snapshot that exists for that VM when Veeam is trying to create its temporary snapshot. I can create a snapshot through VMWare. The latest version of VMWare tools is installed on all VM’s.

Is there a way to set a parameter in Veeam so that when it tries to make a replica of a VM, if it sees a snapshot for that VM that already exists, it can skip making that replica or move on to the next VM? The problem is that when it tries to create that temporary snapshot and hangs, the VM is hung and users can’t connect to it. It stays hung up for over 2 hours, so it causes downtime while attempting this temporary snapshot creation.

If there is no parameter for this, is this something that can be considered to be added as a new feature? I'm sure users would rather the VM be skipped for replication than be hung up and inoperable for two hours trying to replicate it.

Thanks for your consideration.

Justin Matthews
First Banking Services

[PetrM]

Hi Justin and Welcome to Veeam R&D Forums!

It looks like a technical issue at the level of vSphere. Did you try creating two snapshots in a row manually without Veeam, for example, in the vSphere Client? Do you see the same issue? If so, I think it would be best to contact VMware support to determine the root cause.

Thanks!

[Andreas Neufert]

Is it on NFS storage with HotAdd Processing Mode?

[s88urd85]

There is an article which may cover this, if VMs are hosted on NFSv3 storage and Hot Add is used.
https://knowledge.broadcom.com/external ... Id=2010953

[jcm7770]

Thanks for the replies. The VMs are hosted on VMFS Storage, not NFS.

[Andreas Neufert]

I suggest then working on fixing this situation as it is not common. Maybe start a Veeam ticket and work with our support on it. Share here the ticket number, so that the Veeam team here can follow.

[jcm7770]

I already opened a Veeam ticket for this issue (Ticket #07616312) and Joshua Leach suggested that I submit a feature request for this issue to suggest that Veeam add a feature to skip replicating a VM when it detects that the VM has a snapshot so that this issue doesn't occur, which is why I posted on this forum.

[PetrM]

Hi Justin,

I would first try to understand why the VM stops responding during snapshot creation. As I mentioned earlier, you may want to conduct an experiment without Veeam at all: try to create two snapshots in a row manually, for example, in the vSphere Client. If you encounter the same problem, I recommend working with VMware support to determine the root cause of this infrastructural issue. You may also take a look at this KB for more information about basic troubleshooting. It addresses a slightly different problem, but the same troubleshooting plan can work in your case.

If you cannot reproduce the issue without Veeam, please continue working with our support team. By the way, you have an option to escalate the case.

Thanks!

[jcm7770]

I just created a second snapshot within VMWare on our ManageEngine VM, as there was already a snapshot that existed from 3/21. The second snapshot took 4 minutes to create, so the issue isn't in the infrastructure, and it seems that it is only within Veeam when it happens. I looked at the KB article you sent the link for, and all of my proxies are set to only Direct Storage Access, because my proxies are all physical servers and not virtual servers, and that was recommended by Veeam support when I opened another case back in 2023. Within the proxy configuration, the check box is enabled to Failover to Network Mode if primary mode fails or is unavailable. Not sure if that makes a difference. I guess I'll reopen the case that I had opened where they told me to add a request to this forum.

[Andreas Neufert]

Hi Justin, I read through the old closed support case, and I really think that we should find out the root cause of your issue. Your scenario is so widely used that we would have thousands of support cases continuously. Let me try to escalate the case to allow support team to find with you the root cause.

[PetrM]

Hello,

I don't know how, but I overlooked Justin's last reply. I would like to expand on Andreas's comment:
1. The test that I proposed is just a very basic troubleshooting step that is absolutely necessary. The fact that you could not reproduce the same behavior suggests that the equation has a few more variables than I initially thought. Nevertheless, it will be useful for the support team to develop the optimal troubleshooting plan.
2. Veeam does not create or delete snapshots. We play the role of the requester and simply ask the hypervisor to create or delete a snapshot. Therefore, the processes of snapshot creation and deletion are fully managed by the hypervisor.

Thanks!

[jcm7770]

I understand that Veeam doesn't create or delete snapshots. My question is, if Veeam understands that it's a known problem where a VM gets locked up for an inordinate amount of time when it requests a snapshot be created and a snapshot already exists (because it has been reported in knowledge base articles, etc.), wouldn't it be a good idea to implement a feature add where, when Veeam goes to request the hypervisor to create a snapshot, for Veeam to check to see if a snapshot exists first, and if it does, then bypass the request, skipping the replication of that VM and notating that in the logs so that the customer sees it was skipped because a snapshot exists. That way, Veeam doesn't send the request and hang the VM up in the process, and the customer can decide to delete the existing snapshot if it is no longer needed, and then retry the Veeam job? Wouldn't that be a good feature request, or am I missing something?

[Andreas Neufert]

This is what I was trying to say. It is not normal and it would be very bad if this would happen regularly. This is why I asked to go back to the support case and work on your specific situation.

If I understand the notes from support case correctly, then you asked for a feature request to workaround and support automatically asked you to come here for it. The support team did not investigate the issue further from there. As I said it would be very bad if this happens all the time within our 450.000 VMware customers and we would have heard this more commonly. My guess is that there is a special configuration or situation in your environment that lead to this specific issue and we should check exactly what it is and try to solve it or at least learn the real root cause. Not any workaround (feature request as proposed) is a good idea to "just add" to all customers.