STOP the restore process if the target VM is powered on

[Bossa1]

Hi All,

I have a customer that had an outage as one of their employees ran a restore of a VM in their DR site and it overwrote the production VM. He selected the incorrect infrastructure and ignored the warnings. Is there a way of avoiding this issue? The CIO wants Veeam to have a functionality where it wont allow you to proceed with the restore if the current VM is powered on. Is this possible?

Best
Daniel

[PTide]

Hi,

Would you elaborate on the request a little bit, please? Specifically - should a situation when an admin actually wants to overwrite the target VM occur, what behaviour would you expect from Veeam? I'd assume that the proper way of handling that would be to make Veeam to ask for shutdown confirmation and prompt for vCenter password confirmation. On the other hand, given the circumstances, I'm not sure if that would help.

Thanks

[Bossa1]

Hi there,

Well the client actually wants an out right deny when any user wants to restore a VM that is currently powered on. Hence the only way that VM can be overwriten is when its shutdown.

Best
Daniel

[PTide]

Ok, so they want such behaviour that the only way to shutdown a VM would be to shut it down manually. Also I'd like to clarify whether the VM has been restored into the same infrastructure (the same vCenter), or into a different one?

Thanks

[Bossa1]

Well rather the only way to restore a Vm to its original location would be for it to be shutdown prior. So if the VM is powered on Veeam should not allow you to proceed with the restore. The VM was restored to the same vCenter as the running original.

[mkaec]

That's seems like a sensible safeguard to me. Having to manually shut down the VM would reduce the chance of a mistake.

[Bossa1]

Now if Veeam could only have this functionality implemented. Or perhaps there is a way?

[PTide]

Technically that is possible. For now there are no plans to change the current behaviour. Should there be more demand for this change, we will consider putting this modification on our roadmap.

Thanks

[Gostev]

For one, this change will make self-service VM restores more complicated

It's not unusual that VM is borked to the point where you can't logon to shutdown one from inside, however there are not too many environments where regular users have access to vSphere Client to be able to shutdown one from the outside...

[eugene.browne]

I feel your pain. There's probably no way your customer will accept you telling them they need to train their users to heed warning messages. As they say, you can't fix stupid. Could it also be a case where the message was not descriptive enough, or didn't contain enough exclamation marks!!!!!? That, I think is an easier "fix". Another possibility is that it didn't out-rightly state that the VM was being restored to the original location but then that's not necessarily a problem either depending on environment.

[lightsout]

A technical solution to a training issue?

I would perhaps suggest something different, like a pop-up which can't be cancelled for 20 seconds or so, which has a big warning of it. So they can't just go next -> next -> next.

[mkaec]

I've learned in software development that any mistake that is possible for your users to make will be made by them. It's not enough to tell the user that a field is numerical. You need to actively reject non-numerical data.

[PTide]

I would perhaps suggest something different, like a pop-up which can't be cancelled for 20 seconds or so

At this point I imagined an admin having his neural cells dying while awaiting for the countdown to finish, and there is his boss pressing him to start restore immediately. Sure, 20 seconds might not seem like a long span, however in some circumstances that might be pretty unnerving.

[pkelly_sts]

Seems like a reasonable request (as an optional feature at least) though I suspect a given user would only make the mistake once

(I'm not immune to silly mistakes myself I hasten to add!)

[csydas]

Optional feature seems like the right answer, but truthfully, you cannot engineer PEBKAC errors away. At best, you can engineer a scapegoat in. The poor admin in the original post ignored the warnings, and nothing invokes creativity like a user with "enough to be dangerous" knowledge being told they can't do something.

Every time I think of stuff like this, I try to imagine how it could potentially screw me in the long run. While I love Veeam, the very nature of relying on so many components outside of Veeam's direct control raises the probability of a problem kicking up. The last thing I want is a situation in which Veeam mistakenly thinks I've got a production machine live when I urgently need to restore the machine. I'd rather just be sure to dot my i's and cross my t's when it comes to restores than introduce additional failure points.

But that's just my $.02. The short version of this rant is you can't engineer PEBKAC away.

[AlexB82]

Or maybe a confirmation box where you have to type "yes" or "accept" in order to proceed.

[mkaec]

There have been times when I've been doing something, a warning popped up, and I took a moment to consider if I should proceed. And, in some cases, I did cancel the operation because I realized I made a mistake. So, it's not fair to say that warning dialogs are completely useless.