Veeam Backups cause loss of connectivity on Windows XP clien

[andreash]

Hi,

we are trying to back up a Windows XP Client via Veeam 7, but when the backup starts the XP Client loses connectivity.

I get the following error in the Veeam log:

Code: Select all

Processing 'PLM-IXI' Error: RPC function call failed. Function name: [GetFreezeState]. Target machine: [192.168.41.13]. RPC error:Der Remoteprozeduraufruf ist fehlgeschlagen. Code: 1726

The Client System logs shows this:
05:35: Sophos Message Router not available
05:17: Services stopped:
   MS Software Shadow Copy Provider
   Volumeshadowcopy
05:06: Loss of network connectivity (can not reach Domain Controller)
05:00 Starting Services:
   Distributed Transaction Coordinator
   COM+ Systemanwendung
   MS Software Shadow Copy Provider
   VeeamVssSupport

The VeeamVssSupport service remains in state "started" after the backup fails.

Could this be an interaction with Sophos endpoint security? There's only one small other application running on the box.
Unfortunately Sophos doesn't have a simple "shutdown" option.

Regards,
Andreas

[Vitaliy S.]

Hi Andreas,

Yes, most likely this is the reason of the VSS freeze failure. Try to backup this VM without application aware image processing. As an alternative, you may want to add all Veeam processes to the exclusions list, should help as well.

Thanks!

[andreash]

Hi Vitaliy,

thanks for your quick feedback. I have tried to backup this VM without guest processing, and the backup has succeeded. Unfortunately the VM still has lost Network connectivity during the backup and needed to be restarted.
Any idea how to work around this?

Regards,
Andreas

[Vitaliy S.]

Did it lose the connection during snapshot commit operation?

[andreash]

Hi Vitaly,

both manually creating and deleting a snapshot leads to permanent loss of connectivity. This apparently is not directly related to Veeam, though I haven't found any reports of ESXi 5 and XP behaving this way.
VMWare Tools are installed, but I didn't even request to quiesce the guest file systems.

Regards,
Andreas

[foggy]

Short period of inactivity due to the required stun to commit snapshot data is expected during snapshot creation and removal if your primary storage lacks performance.

[andreash]

"both manually creating and deleting a snapshot leads to permanent loss of connectivity"

Connectivity is lost until the server is rebooted. We waited several hours, but connectivity would not recover.

[foggy]

Wow. That's definitely not expected. Since this is reproduced on manual snapshots, I would contact VMware for clarification.

[dellock6]

I had kind of the same problem years ago with almost the same situation, a small Oracle 8 system installed on top of a XP machine (not my design, crappy choice by the software vendor). After every snapshot commit (both with Veeam or with vCenter) the VM needed to be rebooted because the service was crashing.
At the end we simply replaced the VM with a Windows 2008, and all problems went away, keeping the same exact software.

And yes, also the storage was a crappy one, but only this VM had these problems.

Luca.

[kjoggerst]

Any information from VMware? I'm having exactly the same issue with an XP VM on ESXi 5.5 on a HP Proliant DL360p host. Veeam support recommended creating a snapshot in vSphere, and this caused total, permanent network connectivity loss until the VM is rebooted. So, it looks pretty clear that this isn't a Veeam problem, but I was hoping someone might have heard from VMware.