Skip to main content

Delay while step "Preparation of VM" Hyper-V 2016 Agentless

Thread needs solution

Hi, anyone has notices this delay which appears before creating snapshot of a Hyper-V 2016 VM?

I tried on different server with clean installation, the step is immediate after reboot of hypervisor, so increase reaching 20 minutes for every VM after some weeks.

No AV, very fast machine (XEON, 32/64GB RAM, SSD, light VM for tests). Disk backup activity is very fast, much more than the preparation step. Tried with or without CBT enabled.

 

2018-08-22T20:30:03:320+02:00 10844 I0135003A: L'utente '' (clientProfileID=; clientSessionID=59DC7712-08E1-4A3B-80AF-837BF462C69E) sta eseguendo il comando 'Piano di backup 'BackupVM''.

2018-08-22T20:30:18:794+02:00 22972 I0135003A: L'utente '' (clientProfileID=; clientSessionID=59DC7712-08E1-4A3B-80AF-837BF462C69E) sta eseguendo il comando 'Agente selezionato: MILESI-SRV2016'.

2018-08-22T20:30:18:795+02:00 22972 I0135003B: Il comando 'Agente selezionato: MILESI-SRV2016' è stato completato correttamente.

2018-08-22T20:30:18:624+02:00 22972 I0135003A: L'utente '' (clientProfileID=; clientSessionID=59DC7712-08E1-4A3B-80AF-837BF462C69E) sta eseguendo il comando 'Backup'.

2018-08-22T20:30:18:694+02:00 22972 I00000000: I00000000: Backup Inclusions list:

2018-08-22T20:30:18:694+02:00 22972 I00000000: I00000000: WebServer

2018-08-22T20:30:18:695+02:00 22972 I00000000: I00000000: Archive: //192.168.1.210/BackupVM/\WebServer-33D48354-69DB-4E33-864D-4AFB89E57854-4C94150F-5D5F-4160-BA80-A3E9B6D44990A

2018-08-22T20:30:18:701+02:00 22972 I00BD0000: Backup della macchina virtuale 'vm:4C94150F-5D5F-4160-BA80-A3E9B6D44990?type%3dmshyperv'

2018-08-22T20:30:18:917+02:00 22972 I0135003A: L'utente '' (clientProfileID=; clientSessionID=59DC7712-08E1-4A3B-80AF-837BF462C69E) sta eseguendo il comando 'Preparazione per il backup della macchina virtuale'.

2018-08-22T20:42:06:627+02:00 22972 I00950000: Modalità Changed Block Tracking selezionata: 'Non utilizzare CBT'.

2018-08-22T20:47:59:988+02:00 22972 I0135003A: L'utente '' (clientProfileID=; clientSessionID=59DC7712-08E1-4A3B-80AF-837BF462C69E) sta eseguendo il comando 'Creazione snapshot coerente con l'applicazione (VSS)'.

2018-08-22T20:47:59:889+02:00 22972 I0135003B: Il comando 'Preparazione per il backup della macchina virtuale' è stato completato correttamente.

2018-08-22T20:47:59:989+02:00 22972 I00490000: Creazione snapshot coerente con l'applicazione 'AcronisBackup'...

0 Users found this helpful
frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 22
Comments: 3800

Hi,

The "Preparazione per il backup della macchina virtuale" stage is where the VM is "searched" on the Hyper-V host (in order to open its disks by IDs) by the backup engine. This search is performed through WMI calls and the issue could be related to WMI response slowdown, however this is only a guess which needs confirmation. For proper investigation of the issue please contact our support team for assistance. The logs from the Hyper-V host will be required for analysis (see https://kb.acronis.com/content/58301).

Thank you.

In reply to by truwrikodrorow…

Hi,

Thanks for reply. The case 03335441 is opened for other problems and this  (the Last not closed).

 

On Three new servers with Clean OS installation the problem is the same (no drivers of third parts or av installed).

How to check directly wmi response?

Thanks

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 22
Comments: 3800

Hi Davide,

Thank you for the update. In order to reveal potential issues with WMI there are no simple means, since there could be a lot of different WMI calls performed and the main goal is to discover which one in particular is causing the slowdown. It may be even not WMI-related issue and the slowness should be analyzed separately by adding more debug logs into the agent to see what's taking so much time. As far as I've checked with our QA team, we haven't seen similar behavior in our QA labs, so this slowness should be specific to particular environment setup (could be some settings which add the impact).

P.S. I will also followup with our support team regarding the ticket you've submitted to ensure it's processed properly.

Thank you.