Management Server resends email notifications on unexpected restart
Hi,
when the AB12 management server (Windows VM) crashed and rebooted all notifications within last 24 hours are resend via email.
I have seen this twice, is it expected behavior?

- Anmelden, um Kommentare verfassen zu können

It looks like it is reproducible. Emails are resend on a (maybe VMware related) unexpected Windows crash/restart for last hours. Mails sent more than 26 hours ago were not resent.
More about the Windows crash...
Have found no clues in Windows event log but following in mms.log immediatly before crash (by log time):
2016-12-12 18:48:11:382 3344 I00530000: service_process(3840): Die virtuelle Laufwerksdatei '[vsan-ha-disk] fe37ed57-19c5-f5e5-4e9a-00259082e134/Sltbreads03-000002.vmdk' wird geöffnet.
2016-12-12 18:48:23:620 2992 I00000000: Taking decision on error '5439784' with reattempts available '5' and reconnects available '1'
and some logging in vmware.log (from VM, 1hrs time diff because of timezone):
2016-12-12T17:48:29.994Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5717a421-7a694d7d-2cdf-0025908eb2a0/Sltbrevmdr02/Sltbreads03-000002.vmdk-delta.REDO_ZnrLE1" : open successful (1115153) size = 0, hd = 0. Type 8
2016-12-12T17:48:29.994Z| vmx| I125: DISKLIB-LIB_BLOCKTRACK : Resuming change tracking.
2016-12-12T17:48:30.004Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5717a421-7a694d7d-2cdf-0025908eb2a0/Sltbrevmdr02/Sltbreads03-000002.vmdk-delta.REDO_ZnrLE1" : closed.
2016-12-12T17:48:30Z[+0.005]| vmx| W115: Caught signal 11 -- tid 422992 (addr 0)
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: rip 0x95640ac rsp 0x3fffdd5d150 rbp 0x3fffdd5d190
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: rax 0x0 rbx 0x324e5ca8 rcx 0xb79eea8 rdx 0x324e5c50 rsi 0xb79eea0 rdi 0x324e7200
2016-12-12T17:48:30Z[+0.005]| vmx| I125: r8 0x324e7100 r9 0x67450 r10 0x0 r11 0x246 r12 0x0 r13 0x1 r14 0x324e5ca8 r15 0x3fffdd5d278
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D150 : 0x000003fffdd5d190 0x00000000324e7200
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D160 : 0x0000000100000001 0x00000000324e7920
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D170 : 0x00000000324e33c0 0x00000000324e5ca8
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D180 : 0x0000000000000000 0x0000000000000001
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D190 : 0x000003fffdd5d1d0 0x0000000009564e76
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D1A0 : 0x00000000324e5ca8 0x00000000324e5ca8
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D1B0 : 0x0000000000160009 0x0000000000000000
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SIGNAL: stack 3FFFDD5D1C0 : 0x00000000324e3030 0x000003fffdd5d278
2016-12-12T17:48:30Z[+0.005]| vmx| I125: Backtrace:
2016-12-12T17:48:30Z[+0.005]| vmx| I125: Backtrace[0] 000003fffdd5cc70 rip=000000000944a07e rbx=0000000009449b60 rbp=000003fffdd5cc90 r12=0000000000000000 r13=000003fffdd628c0 r14=000003fffdd5d1d0 r15=000000000000000b
2016-12-12T17:48:30Z[+0.005]| vmx| I125: Backtrace[1] 000003fffdd5cca0 rip=00000000094b5cbc rbx=000000000000000b rbp=000003fffdd5ce70 r12=0000000000000000 r13=000003fffdd628c0 r14=000003fffdd5d1d0 r15=000000000000000b
2016-12-12T17:48:30Z[+0.005]| vmx| I125: Backtrace[2] 000003fffdd5ce80 rip=000000000036800f rbx=00000000324e5ca8 rbp=000003fffdd5d0c0 r12=000003fffdd5cf00 r13=0000000000000001 r14=00000000324e5ca8 r15=000003fffdd5d278
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SymBacktrace[0] 000003fffdd5cc70 rip=000000000944a07e in function (null) in object /bin/vmx loaded at 0000000008d44000
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SymBacktrace[1] 000003fffdd5cca0 rip=00000000094b5cbc in function (null) in object /bin/vmx loaded at 0000000008d44000
2016-12-12T17:48:30Z[+0.005]| vmx| I125: SymBacktrace[2] 000003fffdd5ce80 rip=000000000036800f
2016-12-12T17:48:30Z[+0.005]| vmx| I125: Unexpected signal: 11.
This happened while a backup was running. I'm unsure if this could be a VMware bug while accessing snapshots or can be caused by Acronis.
- Anmelden, um Kommentare verfassen zu können

Raphael,
From your description it looks like you're trying to back up a VM which runs Acronis Management Server and the Agent for VMware via this same Agent for VMware in agent-less mode.
The crash from vmware.log according to this thread may occur due to host/guest memory issue especially on heavily loaded systems, so it might be related to the above described case.
Even if this Windows VM runs only Acronis Management Server while the Agent for VMware (appliance or Windows agent) is running elsewhere, it makes sense not to backup this VM as a VM, but install an Agent for Windows inside it and back it up as usual "physical" machine. After you install an Agent for Windows inside this VM, it will appear twice in Devices list in web console with different "type" icons - the icon tooltip will tell how this machine will be backed up (agent-less or via agent inside).
If the above doesn't help then it makes sense to contact our support team for further assistance.
Thank you.
- Anmelden, um Kommentare verfassen zu können

It was an agentless backup of a DC (this time), Win 2012 R2, vSAN datastore. The VM crash does not happen every time on running backups from this VM but I can say when it crashes a backup is running.
Host metrics looks normal, max 30% CPU load and below 2MBit/s on vSAN (@max 3ms), network load below 10MBit/s.
Will run some tests with/without Agent inside and on different ESXi hosts to ensure it is not a heavy load and/or memory issue. Also reducing the console screen resolution as mentioned in linked thread.
Thanks!
- Anmelden, um Kommentare verfassen zu können