Does anyone have experience performing physical-to-virtual Windows MSCS clusters with Veeam VBR?
Best answer by MicoolPaul
View originalDoes anyone have experience performing physical-to-virtual Windows MSCS clusters with Veeam VBR?
Best answer by MicoolPaul
View originalSome experience, what roles are the cluster providing?
Providing quorum is maintained, everything is fine typically using Veeam Agent and restoring as a VM.
Which OS version as well?
Some experience, what roles are the cluster providing?
Providing quorum is maintained, everything is fine typically using Veeam Agent and restoring as a VM.
Which OS version as well?
MS Windows 2008 R2.
As
And of course, if you want to do a test run of this, DataLabs will show you what’s really gonna happen!
As
And of course, if you want to do a test run of this, DataLabs will show you what’s really gonna happen!
I’d also install VMware Tools prior to migration, so you’ve got all your drivers ready.
Why on earth has this never occured to me as I perform P2V and V2V migrations to VMware. Never. And it totally makes sense.
As
And of course, if you want to do a test run of this, DataLabs will show you what’s really gonna happen!
Hi
The run down in general:
Pre-requisites:
With those points covered, for the upgrade process, I’d perform the initial backup, being sure to exclude any cluster disks from the backup. After initial backup, I’d set one of the cluster nodes to maintenance mode/offline gracefully, ensure customer is happy the cluster is still running successfully. Perform final backup and shut down the physical host.
Perform P2V recovery of the node, boot with network disabled, allowing for the multiple reboots for VM hardware installation, IP address reconfiguration etc.
After the reboots are all finished, bring the network mode online again, check the shared resource connectivity is okay where possible, run a report on the cluster to see all nodes are healthy. Return the node to a healthy state in the cluster by exiting any maintenance modes, perform another health check, then finally force the migrated node to be the primary node, and then perform a final report. All should be fine now, onto the next node.
Phone out of battery but hope this provides a good checklist and feel free to ask any questions of anything I’ve said! Thanks.
You can do “DIY” Datalabbing to check it’s behavior and in v12 agents something new coming will make this easier to test.
As
And of course, if you want to do a test run of this, DataLabs will show you what’s really gonna happen!
Hi
The run down in general:
Pre-requisites:
With those points covered, for the upgrade process, I’d perform the initial backup, being sure to exclude any cluster disks from the backup. After initial backup, I’d set one of the cluster nodes to maintenance mode/offline gracefully, ensure customer is happy the cluster is still running successfully. Perform final backup and shut down the physical host.
Perform P2V recovery of the node, boot with network disabled, allowing for the multiple reboots for VM hardware installation, IP address reconfiguration etc.
After the reboots are all finished, bring the network mode online again, check the shared resource connectivity is okay where possible, run a report on the cluster to see all nodes are healthy. Return the node to a healthy state in the cluster by exiting any maintenance modes, perform another health check, then finally force the migrated node to be the primary node, and then perform a final report. All should be fine now, onto the next node.
Phone out of battery but hope this provides a good checklist and feel free to ask any questions of anything I’ve said! Thanks.
Great
Hi
In my opinion it is easier to use a traditional migration method.
Prepare two VMs with all the necessary prerequisites for the O.S. Windows 2008 R2 part and the Vmware best practice part.
Place the two VMs in the MS cluster and perform a failover on the new VMs.
Evict physical servers.
Or do you want to play with datalab?
Done! :)
You can do “DIY” Datalabbing to check it’s behavior and in v12 agents something new coming will make this easier to test.
Rick, any chance V12 will have the capability of testing SureReplica’s on other subnets without having to mess with networks and static routes so that the backup server can find the replica’s in the sandbox at the remote site? SureBackup works great, but SureReplica sure seems to take a bit more finessing to get the ping test and such to work when the replicas reside at a remote site over a VPN on a different subnet. I would assume that’s not what you’re alluding to, so it would be great if it could be changed so that the pings can be sourced from the proxy/virtual lab appliance and not the backup server.
I could see value in deploying either some logic into the virtual lab to make “it” the origin of the tests, with VBR just submitting the test parameters to it, therefore the testing can always take place without network manipulations, as the virtual lab will always need a production subnet IP address anyway that VBR can talk to it on.
I could see value in deploying either some logic into the virtual lab to make “it” the origin of the tests, with VBR just submitting the test parameters to it, therefore the testing can always take place without network manipulations, as the virtual lab will always need a production subnet IP address anyway that VBR can talk to it on.
I’ll do that. I was actually astonished to find out that the traffic didn’t originate from the virtual lab and was from the VBR server instead. I should note that I noted this specific to SureReplica, but my preference is to have the backup server at the recovery site, so SureReplica would work, but SureBackup at the primary site would then have an issue instead. Anyhow, I’ll take that over to R&D. Thanks!
I could see value in deploying either some logic into the virtual lab to make “it” the origin of the tests, with VBR just submitting the test parameters to it, therefore the testing can always take place without network manipulations, as the virtual lab will always need a production subnet IP address anyway that VBR can talk to it on.
I’ll do that. I was actually astonished to find out that the traffic didn’t originate from the virtual lab and was from the VBR server instead. I should note that I noted this specific to SureReplica, but my preference is to have the backup server at the recovery site, so SureReplica would work, but SureBackup at the primary site would then have an issue instead. Anyhow, I’ll take that over to R&D. Thanks!
Please post the link here once you do and I’ll +1 supporting it.
The reason it’s driven from VBR is you can run all of your vbs/PoSH scripts etc from the VBR server for your integration testing.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.