Many people have been reporting network connectivity issues once a Hyper-V Virtual Network Switch is created, but the symptoms vary so widely that it can be tough to find a solution. There are issues like:
- A few packets getting lost every 6-8 hours.
- Complete loss of connectivity on the host operating system.
- VMs work for 3-4 days, then a complete loss of connectivity to the VMs.
This list goes on and on. I've been using Microsoft's Virtualization Technologies since before Virtual Server was first released, and network connectivity has been an issue with every build. Every time Microsoft thinks that they've fixed the issues, they creep right back in. Microsoft has been known to respond with their normal, "We can't reproduce the issue." response, as well. That being said, I think that I've finally found a solution that works for me in each and every case, turning off the "offload" setting(s) of anything IPv4 related within the properties of the driver itself.
If you are using Intel network controllers, then you will most likely not have any issues, as Microsoft does the majority of their testing with intel network controllers. If you are using some other make like Broadcom or Marvell (these 2 in particular), you will most likely run into issues, some of which may even occur without Hyper-V being installed. People using HP servers have also been reporting a large number of issues, but I don't know what chipsets they use. If you are having connectivity issues, turn off all the IPv4 offload settings and see if that fixes your issues. If doing that fixes your issues, or makes a dent, you've found the source.
You can keep disabling properties until you find a combination that works best in your situation, or you can disable/remove the network controller and replace it with a different make and model that is known to be free of issues. The number of features that have been disabled, and the impact that it has on system performance, should determine whether or not disabling features is preferable to replacing the controller altogether. Microsoft needs to get together with these chip manufactures and figure out what the problem is. This is like the old days of DOS, SCSI, and no real standard.
If you are not aware, Visual Studio 2010 (VS) is a complete rewrite of Microsoft's previously popular integrated development system. Previous versions were all written using the Microsoft Foundation Class Library (MFC) and the Win32 API, so Microsoft decided to use their latest technology, Windows Presentation Foundation (WFP), and rewrite the entire UI. It has some very nice new features, but several of the core features that have been around since day one, are not currently available unless you or some one else decides to write an add-on for it.
One small example is the customization of the toolbar. While there is a partial API to work with it, there is virtually no functionality built into the UI. If you want to add Rebuild Selection and Rebuild Solution buttons to the Build toolbar, you can, but you will be stuck with buttons that spell out the entire functionality and will not be able to replace the text with a custom icon. There is an Extension Manager tool called CommandingImage in the Visual Studio Gallery, but it only works if you make all of your changes within a single VS session. If you close VS and then reopen the tool in a new VS session, all previous changes will be overwritten/deleted. Many of you will say that you can live with that, it's just some silly UI customization. Well, that may be so, but that silly UI customization saves me from having to navigate through the menu bar or a context menu every time I want to rebuild something. I rarely ever use the normal Build due to the way it works.
However, this issue is peanuts compared to the real issue, the Offline Help System. With SP1 installed, you can now use it without it hijacking your browser, but over 90% of the MSDN Library still can't, yes CAN'T, be accessed by it. Why? Because Microsoft has not made the packages available for installation, expects everyone to work on-line, and expects everyone to use the web for all of their help requests. I don't know about you, but I only go to the web as a last resort when all else (i.e. local help) fails. They do not care that the on-line help system is significantly inferior (i.e. slower, more difficult to use, and doesn't save your settings) to a local, built-in, help system.
This is not the first time that the help system has changed either. Over the past 13+ years, the help system has been rewritten at least 4 times, and it takes a minimum of 2-3 years for the new system to achieve a level that is equal to the previous system. Of all the previous systems, WinHelp32 was the most reliable, fast, and had the most fully populated reference catalog to date. Unfortunately, that was over 10 years ago. The current help system in VS is barely usable for many tasks, and completely unusable for most tasks (i.e. web development). Try opening a web page with markup, place the cursor over a tag, press F1, and see what comes up. A completely useless HTML Designer page.
As far as I'm concerned, VS 2010 was released at least 2 years early, and as of the date of this post, is missing several core features that have existed since the first release of the integrated development system. If you are thinking about using VS 2010, make sure that you spend at least 3-4 months heavily evaluating it before you make a final decision. If you are only doing Windows Desktop or general library development you may not run into very many issues. But if you are doing any kind of web development, you will be forced to do it without a useful help system. The sad fact is that it is now over a year since VS 2010 was released, and none of these issues have been corrected. Visual Studio 2010 is the developers equivalent to Windows Vista when it comes to development tools. ENJOY!