Sunday, October 24, 2010 5:46 PM
I have a two-node W2008R2 (obviously x64) cluster hosting a number of virtual machines. I learned long, long ago that (a) all VM settings need to be managed from within the Failover Cluster Manager, so please don't tell me that I need to do that or sync the settings; I'm NOT making changes with the old Hyper-V Manager, which I haven't used except to create the virtual network switches when I first built the cluster months ago.
Everything was fine except that one node was prone to BSODs which Dell helped me link back to the drivers for a quad-port Broadcom NIC. I replaced all of those with Intel quad-port NICs. It is important to note that I did NOT make any changes to the virtual networks that already existed on each node. Thus, as each side changed from Broadcom to Intel all I had to do was temporarily change each VM to an internal network, then rebind it to the pre-existing virtual network after creating the appropriate VLANs in the Intel config. This allowed me to avoid having to remove and re-create the VM in the cluster to avoid the dreaded "Network Configuration Error."
The other thing I learned was that the Intel NICs require one to specify the correct VLAN ID on the VM Settings by ticking the "Enable virtual LAN identification" box and then inputting the VLAN ID. This box was grayed out under the Broadcom NICs.
For the few weeks where I had Intel on one side and Broadcom on the other, anytime I migrated from Broadcom to Intel I had to configure this setting to give the VM connectivity. It 'washed away' anytime a migration was done back to the host with Broadcom.
I was unconcerned as I figured once both nodes were the same it would 'stick.' No such luck. So today during my maint window I decided to test completely re-creating a VM in the cluster with all of the Intel VLANs and virtual switch bindings already in place.
I removed a VM from the cluster and re-created it, something I'm quite familiar with. The VLAN ID and checkbox are cleared whenever the VM is migrated between nodes, which is not liveable for the long run.
I am now out of ideas. How does one configure things with Intel NICs in a Hyper-V failover cluster so that the required VLAN ID on the VM Settings doesn't disappear after every migration?
Monday, October 25, 2010 2:25 PMDue to the lack of replies so far, I am filing a paid support ticket with Microsoft. As soon as I have an answer I will post it here in the hopes it might assist others. If anybody beats Support with an answer please post as I just want the issue resolved. Thanks.
Tuesday, November 02, 2010 7:32 AM
I will verify this in five days during our maintenance period but I finally worked my way to a higher level of support and was told that it is because I used Intel ANS on the NIC driver tabs to create VLANs after creating the team. This is on the parents. This is how the Intel support document said to configure VLANs for Hyper-V, and since I had to do something similar with BACS when I had the Broadcom NICs it seemed correct.
The suggested solution is to remove the VLANs from the parents since I don't want to share these connections with them. So on the parents all I will have is the Intel Quad Port NIC showing + the team I create.
Then I will have a single virtual network in the Hyper-V Virtual Network Manager on each parent, bound to this team. Since the names have to match on both nodes for cluster migrations, be careful here. It's not really related directly to this case, but another gotcha in clustered Hyper-V is that the virtual network must already exist and be assigned to the VM when it is made "highly available" or migrations will fail, showing "Configuration Error" instead of your desired virtual network.
I'll have to make sure I'm not missing something, but I think this is going to require me to remove all of the VMs from the cluster so they can be added back with the new, single virtual network. I'll first try re-using an existing virtual switch that I re-bind to the team but fear that any VM not previously using this network will require the process above. I have five VLANs so no matter what several VMs will change switches.
Finally, inside the Settings in Failover Cluster Manager you tick the box and specify the appropriate VLAN ID, as I have been. This is where the virtual switch separates the traffic. The theory is that without the parent also trying to manage VLAN IDs, clustered Hyper-V can retain the setting.
Monday, November 08, 2010 4:30 AM
Well...this did not work. I'm awaiting a callback tomorrow to see where we go next. After removing the parent VLANs and the previous Virtual Networks bound to those VLANs, upgrading the Intel driver and ProSet/ANS software, creating a new team, binding a new Virtual Network to this team (same names on both hosts), and finally binding each VM to this Virtual Switch with the appropriate VLAN ID set inside Failover Cluster Manager Settings for the VM...the same thing happens. The IDs go away after any migration or move to another node.
I'll also note that my fear/experience was correct. If you do not add a VM to the cluster (make it highly-available) WITH the desired Virtual Network, it will fail to migrate and instead display "Configuration Error." In my case, having created a new Virtual Network, to make my VMs able to migrate I have to remove them from the cluster and add them back under the new Network. They still lose the VLAN but I have to be able to Live Migrate or the cluster isn't much good in my environment. At least I can quickly reset the VLAN ID with no other downtime until we solve this.
I'll be back later with whatever we try next, and the results. Hopefully successful.
Monday, November 29, 2010 2:18 PMStill in a holding pattern on this. MS is currently trying to duplicate the issue in their lab and I've sent some additional troubleshooting data to see if we can determine where and how my environment and their test one differ.
Friday, January 21, 2011 2:21 PMAny update on this? We're experiencing the same problem and can't find any way to stop it losing the VLAN ID.
Monday, January 24, 2011 8:46 AM
We've experienced this since we first started using VLAN's in our cluster..
Running a "refresh virtual machine configuration" in the cluster manager before doing a live migration most of the time will ensure the VLAN's stay the same. But with any real-world failovers - it's a gamble if it gets the assigned VLAN id..
I'm hoping for a fix in the 2008r2 SP1..
Monday, April 18, 2011 2:17 PMNo, sadly no update. MS stopped responding to the case and since I hadn't yet paid and wasn't seeing any hope of an answer I allowed the open case to die. I'm just living with the hassle. I too hope that someday a patch will fix this, though SP1 made no difference.
- Proposed As Answer by Daithiol1 Tuesday, April 19, 2011 10:54 PM
Saturday, June 04, 2011 12:39 AMI have a fix. Finally. This is information from my replication vendor, SIOS:
Issue: In a Hyper-V host cluster, if a change is attempted to a setting of a virtual machine, such as adding a new NIC or setting a VLAN ID, an error will be received.
Recommended Action: In order to make such changes, remove the virtual machine from the failover cluster, provision a new virtual machine using Hyper-V Manager (not Failover Cluster Manager) based on the existing VHD file, make the desired changes, then add the virtual machine back into the cluster.
This is basically the opposite of how I was trained. I was told that you always, always, always made any configuration changes INSIDE of the cluster admin and never, ever, ever touched settings in the classic Hyper-V admin, precisely because they weren’t supposed to stick. But the way you add the VM to the cluster (make it highly-available) is different here.
The original SIOS way was to create a brand-new VM right inside the cluster, then bind it to storage and configure it. What’s working is to delete everything, create a new VM inside Hyper-V, get it configured like you want, then right-click at the top of the “Services and applications” in the main cluster admin tree, choose “Configure a Service or Application,” select “Virtual Machine,” then select the one you just created. Finish off the clicks and it will be highly-available. In my SIOS DataKeeper environment you’ll get a warning because the storage isn’t automatically provisioned.
So you right-click the new VM in FCM and Add Storage, selecting the disk you removed from the original VM. Make any other choices like preferred node and fire it up.
- Marked As Answer by RandomParsley Saturday, June 04, 2011 12:39 AM
Sunday, August 07, 2011 1:54 PM
This question/answer from Laura Zhang - MSFT appears to correctly fix the problem. You must refresh the config into the cluster. Please see below.
Question - Q2: Virtual machine settings that are changed on one node in a Windows Server 2008 Failover Cluster are not present when the VM is moved to another node.
Symptom - Virtual machine settings that are changed on one node in a Windows Server 2008 Failover Cluster are not present when the VM is moved to another node.
Possible Cause - The cluster resources for a virtual machine (VM) store configuration information about the VM. This information is used to configure the virtual machine on the other nodes of the cluster if the VM is moved to a different node. If you do not refresh this information for a clustered VM after you modified the settings of that VM via the Hyper-V manager, the Hyper-V Failover Cluster is not able to correctly record the change and configure the VM when it is moved to another node.
Resolution - When virtual machine settings are changed on a VM that’s on a Failover Cluster, you must select the Refresh virtual machine configuration option before the VM is moved to another node. To do so, please perform the following steps:
1. In Failover Cluster Manager, select the virtual machine. There will be an item in the Action pane Refresh virtual machine configuration.
2. Click Refresh virtual machine configuration.
Sunday, August 07, 2011 4:08 PMThis was one of the first and most obvious things to try and it made absolutely no difference in my particular situation. The real fix is as I noted in my reply of June 4, 2011, which I marked as the answer.
Wednesday, November 09, 2011 5:26 PMThank you for posting this solution, RandomParsley. I have a two node 2008R2 cluster with Intel Pro/1000 PT Dual Port Server Adapters teamed and trunked to the virtual switch. Building this cluster following typical instructions of creating the virtual machines inside Cluster Manager resulted in the virtual machines losing their VLAN ID upon failover 100% of the time. Switching to your posted solution of creating the virutal machines in Hyper-V and using Configure a Service or Application in Cluster Manager to import the virutal machine solved the problem. Now I am wondering if this is only an issue with Intel adapters or are Broadcom adapters also experiencing this.
Saturday, February 04, 2012 9:23 PM
Just to add another success story here:
We ran into the very same problem when we rebuilt a client's Hyper-V cluster. It uses Broadcom NICs for the vSwitches (with BACS-built teams). Everytime we migrated those machines that had VLAN IDs configured, the VLAN settings were gone.
We recreated the VMs with the steps above - et voilà, VLAN IDs stay attached. Very fine.
Thanks for the solution - however, it really seems that something inside Hyper-V is not built as solidly as it should. I hope v3 in WinSrv8 will do better ...
MVP Directory Services
Saturday, February 11, 2012 10:35 AM
I have same problem. I have 2 host Hyper-V cluster (first server hase Broadcom NICs (with BACS-built teams), second has Intel NICs (with PROset). VMs without VLAN setting migrate normal. But everytime I migrated VM that had VLAN IDs configured, the VLAN settings were gone.
Hyper-V VLAN configuration methods based on Broadcom NICs (with BACS-built teams) and based on Intel NICs (with PROset) aren't compatible (Intel demands to specify VLAN IDs).