Stop VMs with system setting vs CBT vs VBR7

[Frosty]

Hi all,

We have recently integrated Eaton's Intelligent Power Manager (IPM) v1.50 with our VMware hosts. Our configuration doesn't involve vCenter; rather, IPM communicates directly with our 3 x ESXi 5.1 hosts.

The hosts are configured to "Allow virtual machines to start and stop automatically with the system" and the selected Shutdown Action for each host is "Guest Shutdown". All of this works more-or-less as one might expect ... power goes out, 10 mins later VMs start shutting down, then the host shuts down.

BUT

Next time VBR backup jobs ran, a CBT-related warning was issued in every job which had a VM which had been shutdown at the last power-out, auto-VM-and-Host-shutdown event: "Cannot use CBT: Soap fault. Error caused by file ... [etc etc]"

My question: is there any easy way to prevent this CBT failure on the next backup run, or will I have to live with it?

I suppose I could manually run some backups right afterwards, thus clearing the CBT issue before the next regularly scheduled backups needed to run, but that's a bit of a clunky workaround. I was hoping there might be a more elegant solution.

[Gostev]

Hi, Stephen

This CBT event can pretty much be ONLY caused by dirty shutdown due to a power loss. And running the job once is the only way to fix it.

Was your entire infrastructure (VMs, hosts and shared storage) shutdown properly? Is it possible that some VMs took longer than 10 minutes to shutdown (you know, Windows likes to do this sometimes), resulting in eventual hard power off? This should be clear from the Windows Event Log on the impacted VMs. Same for hosts - is it possible that they took longer to shutdown and battery ran out?

Thanks!

[Frosty]

Mmmm. Yes, it seems you are correct. It looks like the host did NOT do a graceful VM shutdown; it might have just turned off the VMs as it was shutting down. Back to the drawing board. Damn.

[Frosty]

Confirmed that at least SOME of my VMs did shut down gracefully. But some got powered off hard. Then I found this:

http://kb.vmware.com/selfservice/micros ... Id=1008182

Seems to be some kind of VMware bug? Looks like I need to move ALL the VMs up into "Any Order" group (for Startup Order) and then back down again to "Manual Startup". This can be caused by loss of the setting after a vMotion activity. We do that a fair bit here due to patching and rebooting hosts.