DRAG DROP
Your network contains an Active Directory domain named contoso.com. The domain
contains four member servers named Server1, Server2, Server3, and Server4. Server1 and
Server2 run Windows Server 2008 R2.
Server1 and Server2 have the Hyper-V server role and the Failover Clustering feature
installed. Failover
Clustering is configured to provide highly available virtual machines by using a cluster
named Cluster1.
Cluster1 hosts 10 virtual machines.
Server3 and Server4 run Windows Server 2012 R2.
You install the Hyper-V server role and the Failover Clustering feature on Server3 and
Server4. You create a cluster named Cluster2.
You need to migrate cluster resources from Cluster1 to Cluster2. The solution must minimize
downtime on the virtual machines.
Which five actions should you perform?
To answer, move the appropriate five actions from the list of actions to the answer area and
arrange them in the correct order.
Answer: 
Explanation:
http://blogs.technet.com/b/hugofe/archive/2012/12/06/best-practices-for-migration-of-clusterwindows-2008-r2-2012-as-melhores-praticas-para-migrar-um-cluster-de-windows-2008-para-windows-2012.aspx
1. Launch the Cluster Migration Wizard from the Failover Cluster Manager
i. The source VMs should be shut down and turned off.
ii. The source cluster CSV volumes that have been migrated should be off-lined.
iii. The storage that is common to both clusters (LUNS) should be masked (hidden) from the source cluster, to prevent accidental usage by both clusters.
iv. The storage that is common to both clusters (LUNS) should be presented to the new cluster.
v. The CSV volumes on the target cluster should be on-lined.
vi. The VMs on the target cluster should be on-lined.
vii. VMs are migrated and ready for use
http://blogs.msdn.com/b/clustering/archive/2012/06/25/10323434.aspx
1. From Failover Cluster Manager in Cluster1, run the Migrate a Cluster Wizard.
2. Shut down all of the virtual machines in Cluster1.
3. Mask the shared storage to prevent the storage from being accessed by Cluster1.
4. Unmask the shared storage to present the storage to Cluster2.
5. Start the virtual machines in Cluster2.
I dissagree here, following the article: http://blogs.technet.com/b/hugofe/archive/2012/12/06/best-practices-for-migration-of-cluster-windows-2008-r2-2012-as-melhores-praticas-para-migrar-um-cluster-de-windows-2008-para-windows-2012.aspx
1. On Cluster 2: migrate a cluster wizard
2: Shut down VM´s on Cluster 1
3. Unmask shared storage on cluster 1
4. Mask shared storage on Cluster 2
5. Start the VM´s on cluster 2
Morten,
The storage is already unmasked to cluster1 and masked to cluster2. During the migration, it cannot be visible to both clusters at the same time or it will cause data issues, so you need to mask it from the original(cluster1), then unmask it from the new destination(cluster2).
I have seen the masking and unmasking that Morten mentions in various articles, however, I am pretty sure that you mask it from cluster one and unmask to cluster 2
Sorry Morton, but this part comes from the article you refere to:
– The storage that is common to both clusters (LUNS) should be masked (hidden) from the source cluster, to prevent accidental usage by both clusters.
– The storage that is common to both clusters (LUNS) should be presented to the new cluster.
– The CSV volumes on the target cluster should be on-lined.
– The VMs on the target cluster should be on-lined.
– VMs are migrated and ready for use!
So the source should be masked and target unmasked.
Pio is correct, however he’s made a type on step 1. Watch out for this!!
1. From the failover cluster manager on CLUSTER2! run the migrate cluster wizard.
2. Shutdown VMs on Cluster1.
3. Mask storage so Cluster1 can’t see it.
4. Unmask storage for Cluster2.
5. Startup VMs on Cluster2.
The reason for this is because you launch the migration wizard on the DESTINATION server. Then you select the SOURCE (cluster1) to migrate the settings over.
Excerpt from the TN articles above:
“Launch the Cluster Migration Wizard from the Failover Cluster Manager, select the source cluster, and then select the cluster roles on the source cluster that you’d like to migrate to the new cluster.”
agree
You’re right, you run the migration wizard on the destination server and point to the source
Well, it seems you are not so “noob” as your nickname suggests.
The key point noted by n00b is that you launch the migration wizard from the destination server, and so, you select the sourceserver from the migration wizard’s interface.
Ok so to clarify things here, taken from Microsoft:
https://technet.microsoft.com/en-us/library/dn530781.aspx
“…And downtime is required: after you copy the Virtual Machine roles to the cluster, you must take the virtual machines on the old cluster offline, unmask the storage to the old cluster, mask the storage to the new cluster, then bring the storage online on the new cluster, and then start the virtual machines on the new cluster.”
This statement just proves the provided answer is correct.
A correction to my statement above:
https://technet.microsoft.com/en-us/library/dn530789.aspx
“When you migrate a cluster role between two multi-node failover clusters, you can prepare the destination failover cluster, configure storage on the new cluster, and copy the cluster role to the new cluster while maintaining service availability on the old cluster. However, customers will experience a brief downtime after the cluster role is migrated and before you bring the role online on the new cluster.
If the new cluster will use the same storage that the old cluster is using, before you bring the role online on the new cluster, you must take the clustered role offline on the old cluster, mask the storage to the old cluster, unmask the storage to the new cluster, and then bring the volumes or disks online on the new cluster.”
This goes in line with provideed answer.
That could be the end of this post. Here youll obtain some websites that we think youll value, just click the hyperlinks.
Just beneath, are many completely not related websites to ours, on the other hand, they are certainly really worth going over.
http://blogs.technet.com/b/hugofe/archive/2012/12/06/best-practices-for-migration-of-cluster-windows-2008-r2-2012-as-melhores-praticas-para-migrar-um-cluster-de-windows-2008-para-windows-2012.aspx