Background:
We had a Windows 2008 Server that is part of a Fail-over Cluster Exchange CCR. We were attempting to move the virtual machine to hot standby fail-over site. The first two attempts resulted in us backing out of the change and reverting to the Main site. Each incident resulting in more confusion to why Exchange is behaving like this after the move.
First Attempt:
The first step we took was to bring down the existing VM. This move is not under one vCenter installation so vMotion was out of the question.
Once we brought up the Guest at the alternate site, this is when the first symptoms began to emerge. With using the same E1000 driver the OS detected a different Network Card thus trumping the original Fail-over cluster interface to disabled state. We attempted to remove the card to no avail, and we reverted to the original state at our main site to try again a different day.
Second Attempt:
This time we approached it a little different and evicted the guest from the cluster, upgraded the virtual hardware, changed the NICs to the VMXNET3 driver and added the paravirtualized SCSI card, and fired it up on the secondary site. Remnants of the original NIC was still in the device manager, the cluster seemed happy but the information stores would not migrate, in fact they wouldn't even initialize.
Revert, Revert...
Third Attempt:
(We are still in the midst of this)
Making sure the VMGuest had been evicted from the cluster, we removed all remnants of NICs, and IP Addresses in use. Moved the VMGuest, and did all the upgrading at the Alternate Site. Had an odd error, when adding the IP address to the host where if the host had a DHCP address, it was perfectly happy, but if I changed the IP and Gateway the OS demanded a reboot and when it rebooted the Gateway was empty. ANY changes that were performed in the Network configuration had the OS request a reboot EVERYTIME. Tried Googling, nothing, tried numerous different configurations and reboots and no change.
Where we ended up fixing the issue was in the registy and through this link:
http://social.technet.microsoft.com/Forums/en-US/itprovistanetworking/thread/27fd86ad-caad-4698-9032-63550695ee3d
Where is talks about this Registry Hive:
We matched the registry settings from the Active Node on the Fail-over cluster, in which we ended up adding two Multi String Keys "DefaultGateway" with the default gateway as the data for the key and "DefaultGatewayMetric" in which we added the value of 0. We also changed the "RegisterAdapterName" to a value of 1 from 0.
We rebooted the VMGuest and are in the midst of re-adding it to the cluster.
I will keep this updated to the outcome of the changes.
--Update--
Well we ended up removing the Guest completely because it still wouldn't add the cluster node. So we rebuilt the VM completely from a template and found when adding the Static IP that the gateway was not resident. Examining the registry I see that the reg entry shows the configured gateway as the second line of the key. Huh? How and why did that happen? We are trying to track down point of why.
We had a Windows 2008 Server that is part of a Fail-over Cluster Exchange CCR. We were attempting to move the virtual machine to hot standby fail-over site. The first two attempts resulted in us backing out of the change and reverting to the Main site. Each incident resulting in more confusion to why Exchange is behaving like this after the move.
First Attempt:
The first step we took was to bring down the existing VM. This move is not under one vCenter installation so vMotion was out of the question.
Once we brought up the Guest at the alternate site, this is when the first symptoms began to emerge. With using the same E1000 driver the OS detected a different Network Card thus trumping the original Fail-over cluster interface to disabled state. We attempted to remove the card to no avail, and we reverted to the original state at our main site to try again a different day.
Second Attempt:
This time we approached it a little different and evicted the guest from the cluster, upgraded the virtual hardware, changed the NICs to the VMXNET3 driver and added the paravirtualized SCSI card, and fired it up on the secondary site. Remnants of the original NIC was still in the device manager, the cluster seemed happy but the information stores would not migrate, in fact they wouldn't even initialize.
Revert, Revert...
Third Attempt:
(We are still in the midst of this)
Making sure the VMGuest had been evicted from the cluster, we removed all remnants of NICs, and IP Addresses in use. Moved the VMGuest, and did all the upgrading at the Alternate Site. Had an odd error, when adding the IP address to the host where if the host had a DHCP address, it was perfectly happy, but if I changed the IP and Gateway the OS demanded a reboot and when it rebooted the Gateway was empty. ANY changes that were performed in the Network configuration had the OS request a reboot EVERYTIME. Tried Googling, nothing, tried numerous different configurations and reboots and no change.
Where we ended up fixing the issue was in the registy and through this link:
http://social.technet.microsoft.com/Forums/en-US/itprovistanetworking/thread/27fd86ad-caad-4698-9032-63550695ee3d
Where is talks about this Registry Hive:
HKLM/System/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/%CLSID%
We matched the registry settings from the Active Node on the Fail-over cluster, in which we ended up adding two Multi String Keys "DefaultGateway" with the default gateway as the data for the key and "DefaultGatewayMetric" in which we added the value of 0. We also changed the "RegisterAdapterName" to a value of 1 from 0.
We rebooted the VMGuest and are in the midst of re-adding it to the cluster.
I will keep this updated to the outcome of the changes.
--Update--
Well we ended up removing the Guest completely because it still wouldn't add the cluster node. So we rebuilt the VM completely from a template and found when adding the Static IP that the gateway was not resident. Examining the registry I see that the reg entry shows the configured gateway as the second line of the key. Huh? How and why did that happen? We are trying to track down point of why.
Comments