Now let's see what happens during a failover situation.
We'll do a test first.
Let's right‑click on the Replica server,
Replication, Test Failover from the flyout,
and it says we can create a separate virtual machine to
verify that the recovery point is valid.
We can choose our recovery point and then click Test Failover.
So you'll notice what's happening here is that Hyper‑V
immediately spawned another instance of that VM,
gave it the name vm02 ‑ Test to avoid a conflict,
and then we can start it and test it.
But notice that the replication engine didn't make an
assumption that we wanted to start it, but it made it available.
And it's booting down below.
It's probably in a stuck state because, like I said,
I don't have an OS on that machine yet.
It's probably not able to resolve the virtual DVD.
In fact, I guarantee that's what the problem is.
Then to clean up, we can come back to the secondary and go to Replication,
and I'm going to do a Stop Test Failover,
and it tells us that the Test VM will be deleted,
and its data would be discarded.
Again, that's for testing purposes anyway.
That's why that's there.
Now to do a real failover, let's right‑click on the secondary again,
Replication, Failover.
Same interface.
You choose your recovery point and click Fail Over.
Now it tells us here we cannot failover the machine
because the primary is not turned off.
We saw earlier in this course the ASR at least will attempt to
stop the machines in the source environment,
but notice that that's not the case with Hyper‑V.
Now if we had a catastrophic problem on our MEM1 host,
like if MEM1 went down, then, by definition,
vm02 would be down.
You see what I mean?
So I'm going to simulate an outage by shutting down the virtual machine here.
Actually, just going to go ahead and turn it off.
And then on MEM2, let's right‑click, Replication,
Failover, click Fail Over,
and we'll see that that machine is simply coming up and online.
And we can expect that, again, it's not mapping to a DVD at this time,
so it's just showing a black error screen.
But that's pretty straightforward and especially so when you think that
you can automate all of this using Windows PowerShell.
It's not like in the real world we have to babysit here in the Hyper‑V
Manager MMC or possibly in Windows Admin Center.
Now,
what does it look like in terms of replication status now that vm02 is the
running machine and the MEM1 instance is in an off state?
What does that mean with regard to replication health?
Let's actually go to the running instance,
right‑click, Replication, View Replication Health.
Okay, so it says Failover complete, and it says for Replication Health,
it's in a Warning state.
It says, Choose Reverse Replication to resume replication.
So again, it's very similar to what we saw with Azure Site Recovery.
After you perform a failover, the replication then is over with,
and you have to manually re‑enable it.
I like how if there is an error,
notice that we can view events to tap into Event Log conveniently.
Well, at least I tried.
There we go.
It looks like clicking the link slowly invokes the event
viewer console and brings it in here.
And this is actually a good log to know about,
as you can see, Hyper‑V‑VMMS, Admin, Networking,
Operational, and Storage.
And this allows us to track enabling replication,
initial replication completed successfully,
and so on and so forth.
And you can get to that Hyper‑V‑VMMS, let's follow the path here,
we've got an Event Viewer, Applications and Services Logs,
Microsoft, Windows, Hyper‑V‑VMMS.
Okay.
All right, so let's close out of here,
and again we'll right‑click the virtual machine on the secondary,
now the primary, and we'll do a Reverse Replication.
This kicks open the wizard here, so let's go ahead to the first step.
Our Replica server now is going to be replica one.
Now it mentions, the text is kind of small, but I want to repeat this,
that if the Replica server is in a failover cluster,
you're going to specify not the node, but the Hyper‑V Replica Broker clustered
role that you would create as a prerequisite. Important.
So let's go Next here. Says that the specified Replica server is not configured.
Well, again,
it reminds me of how much of this is manual, and I'm just thinking of
how we can automate this with PowerShell. Sure enough,
we'd have to come back to MEM1, go back to Hyper‑V Settings, and make
sure that now we have replication enabled here.
So let me set here the settings that we previously had on
MEM2. Looks like it didn't take my choice.
So I've got Enable this computer, Use Kerberos,
Allow replication from any. Click OK. All right. So let's go back to where we
were before here on vm02, Replication, Reverse Replication.
We'll go Next, MEM1.
Yes, that's right. We're doing Kerberos. Yes, that's right. Compress.
I'm just going to leave everything the same as it was originally here. Next,
Next, Finish.
Great.
So at this point, now we've got vm02 running on MEM2 as the running
active instance, and vm02 is in an off state on MEM1. You know what
we're going to do to reinstate everything, right?
We're going to right‑click, go to Replication.
Well, actually, we can't do it here on the source.
I had mentioned this before, planned versus unplanned failover, right.
So we're going to want to go to what is now the replica, MEM1,
right‑click vm02, Replication, Failover, Fail Over.
Same problem I saw before. I keep getting hit by
that over and over and over again.
I'm just going to go ahead and turn off vm02. Let's go back to MEM1, clicky,
clicky, click. Good repetition here. Good adult learning,
right?
Failover, Fail Over.
Okay.
And then, as we would expect,
we're going to want to reverse replication one more time to
reestablish the original directionality of the replication.
So there you have it.
I hope you're impressed with how straightforward the replication process is when you're doing Hyper‑V Replica here in Windows Server.