Search the Community

I have been stuck with this since last Friday and it's really starting to depress me, as I finally thought I was ready to push ahead with deploying proper new servers when I noticed this behaviour, and it's a problem that involves a great deal of waiting to see if it's fixed so I am bored of watching it now. I'm just testing a new Hyper-V cluster before pushing ahead with production, and when I live migrate my test VM, pings into the server drop for anywhere between 20-100 pings, unless I ping out from the server. So far, so similar to many other issues, and clearly ARP-related - the switch visibly has the incorrect ARP entry until I ping out from the guest. I've run Wireshark captures on both Hyper-V hosts in the cluster on the NIC with the virtual network, and captured the debug output from my HP A5800 switch for ARP packets as well, and as best I can tell, the issue is because Hyper-V never sends a gratuitous ARP out to update the routing tables. Is there anything likely to be stopping these gratuitous ARP packets being sent out by the server? I can see other gratuitious packets being sent round the network on the Wireshark logs. This is all Server 2008R2, hosts and guests, as up to date as can be (apart from this week's patches, not got round to them yet), running a cluster on an FC SAN hosting the CSV, on HP DL380 G7s with a mix of onboard Intel NICs and expansion-card Broadcom NICs. The NICs are teamed but disabling that/changing settings/running on only a single NIC does nothing to resolve the situation. I'm performing the Live Migrations from a third physical server running SCVMM. Has anyone got any clues? I've tried destroying and recreating the cluster and it's made no difference; I don't yet want to rebuild the virtual hosts from scratch because that's a fairly time consuming option. Help, my sanity is at stake

Still trying to wrap my head around all this Hyper-V stuff. I've got two hosts, both dual-socketed with hexacore Xeons, so 12 cores/ 24 threads each, and 32GB of RAM. They'll operate in a failover cluster with live migration in case anything goes wrong. I've got it planned so that the startup RAM for every VM totals 30Gb (leaving two for the host) so that in the case of a failover, one host can manage every VM. I'm then planning on using the dynamic memory to let VMs grow to a higher value when both hosts are up and there's 60Gb of RAM available to use overall. However, I cannot, for the life of me, find out if I can do a similar thing with CPU cores. Does this mean I need to plan my core allocation to fit into the 22 available threads and waste half my processing power for a just-in-case scenario? Or will Hyper-V/VMM allow for CPU oversubscription, where in normal day-to-day activity there's no oversubscription taking place except when one host failsover? Potentially it's not as wasteful as it might seem as it would at least mean that VMs have real cores allocated rather than HyperThreaded Pretend Cores, except when failing over, but it still strikes me as under-utilising resources. Has anyone set this up to know better than Google?