Feature Request - check on failed SureBackup VMs

[mwpreston]

Or SureReplica VMs in my case.

At times we will have some VMs fail inside our SureBackup/SureReplica jobs. Our jobs simply link to all of our offsite replication jobs and turn on each and every VM (3 at a time). At times, for example, some of the Linux VMs will attempt to do a filesystem check on boot - which can take quite a long time depending on the size of disk and storage they are located on offsite. Anyways, long story short the timeout occurs and they report as failed. I know I can increase boot timeouts, but I would like to see a way to simply restart the SureReplica job and specify just those VMs that have failed. Since my automated job happens after hours I never get to see it - being able to restart the job with just specific VMs and confirm that it is simply a filesystem check during the my "regular" worktime would be helpful...

Make sense?

[Gostev]

Yes it does, sounds like we need to add a retry capability similar to one we have in backup job (where retrying only processes failed VMs)?

[mwpreston]

Exactly! Not necessarily an automatic retry (although that would be nice too) but more so a way to manually power on just those failed VMs in a virtual lab to see what exactly is causing the timeout, without having to setup another job containing just those VMs. Then if boot issues are confirmed we can troubleshoot the issues there and take extra caution not to restart our prod vms

Going one step further, leveraging the vSphere API to grab screenshot of the VM console of any VM that times out during the boot process may be helpful as well - not sure how that would be included into the email report though...

[nike284]

I second all the suggestions, this may reduce the need to contact support.

[nefes]

I know, that it is not exactly the same as you ask, but maybe it could help you in some cases:
If you open SureBackup session, right click on failed VM and press Start - you will go to troubleshooting mode.
In this mode only selected VM and all AppGroup VMs that are before it loads.
It also does not turn off VM in question until you manually stop job, thus letting you open it and check what is going wrong.

[jmmarton]

And on a completely different note, I was never a fan of ext3 wanting to always do filesystem checks after X days, because it seems like the checks always occur at the worst possible time. That doesn't change the need for some flexibility on how we handle timeouts, but another thing to consider is disabling those scheduled checks.

Joe

[hyvokar]

Yes it does, sounds like we need to add a retry capability similar to one we have in backup job (where retrying only processes failed VMs)?

Any news on this one? Would come handy.