How to Hot Add/Remove Virtual Network Adapters in Hyper-V 2016

How to Hot Add/Remove Virtual Network Adapters in Hyper-V 2016

Last week I showed you how to hot add/remove memory in Hyper-V 2016 and this week I’m covering another super handy new feature that system admins will also love. In fact, Hyper-V 2016 brought many fantastic features. Containers! It also added some features that indicate natural product maturation. On that list, we find “hot add/remove of virtual network adapters”. If that’s not obvious, it means that you can now add or remove virtual network adapters to/from running virtual machines.

Requirements for Hyper-V Hot Add/Remove of Virtual Network Adapters

To make hot add/remove of network adapters work in Hyper-V, you must meet these requirements:

  • Hypervisor must be 2016 version (Windows 10, Windows Server 2016, or Hyper-V Server 2016)
  • Virtual machine must be generation 2
  • To utilize the Device Naming feature, the virtual machine version must be at least 6.2. The virtual machine configuration version does not matter if you do not attempt to use Device Naming. Meaning, you can bring a version 5.0 virtual machine over from 2012 R2 to 2016 and hot add a virtual network adapter. A discussion on Device Naming will appear in a different article.

The guest operating system may need an additional push to realize that a change was made. I did not encounter any issues with the various operating systems that I tested.

How to Use PowerShell to Add or Remove a Virtual Network Adapter from a Running Hyper-V Guest

I always recommend PowerShell to work with second or higher network adapters to a virtual machine. Otherwise, they’re all called “Network Adapter”. Sorting that out can be unpleasant.

Adding a Virtual Adapter with PowerShell

Use Add-VMNetworkAdapter to add a network adapter to a running Hyper-V guest. That’s the same command that you’d use for an offline guest, as well. I don’t know why the authors chose the verb “Add” instead of “New”.

The above will work on a virtual machine with a configuration version of at least 6.2. If the virtual machine is set to a lower version, you get a rather confusing message that talks about DVD drives:

It does eventually get around to telling you exactly what it doesn’t like. You can avoid this error by not specifying the DeviceNaming parameter. If you’re scripting, you can avoid the parameter by employing splatting or by setting DeviceNaming to Off.

You can use any of the other parameters of Add-VMNetworkAdapter normally.

Removing a Virtual Adapter with PowerShell

To remove the adapter, use Remove-VMNetworkAdapter:

This is where things can get… interesting. Especially if you didn’t specify a unique name for the adapter. The Name parameter works like a search filter; it will remove any adapter that perfectly matches that name. So, if all of the virtual machine’s network adapters use the default name Network Adapter, and you specify Network Adapter for the Name parameter, then all of that VM’s adapters will be removed.

To address that issue, you’ll need to employ some cleverness. A quick ‘n’ dirty option would be to just remove all of the adapters, then add one. By default, that one adapter will pick up an IP from an available DHCP server. Since you can specify a static MAC address with the StaticMacAddress parameter of Add-VMNetworkAdapter, you can control that behavior with reservations.

You could also filter adapters by MAC address:

You could also use arrays to selectively remove items:

You could even use a loop to knock out all adapters after the first:

In my unscientific testing, virtual machine network adapters are always stored and retrieved in the order in which they were added, so the above script should always remove every adapter except the original. Based on the file format, I would expect that to always hold true. However, no documentation exists that outright supports that; use this sort of cleverness with caution.

I recommend naming your adapters to save a lot of grief in these instances.

How to Use the GUI to Add or Remove a Virtual Network Adapter from a Running Hyper-V Guest

These instructions work for both Hyper-V Manager and Failover Cluster Manager. Use the virtual machine’s Settings dialog in either tool.

Adding a Virtual Network Adapter in the GUI

Add a virtual network adapter to a running VM the same way that you add one to a stopped VM:

  1. On the VM’s Settings dialog, start on the Add Hardware page. The Network Adapter entry should be black, not gray. If it’s gray, then the VM is either Generation 1 or not in a valid state to add an adapter:
    harn_newhardware
  2. Highlight Network Adapter and click Add.
  3. You will be taken to a screen where you can fill out all of the normal information for a network adapter. Set all items as desired.
    harn_newadapter
  4. Once you’ve set everything to your liking, click OK to add the adapter and close the dialog or Apply to add the adapter and leave the dialog open.

Removing a Virtual Network Adapter in the GUI

As with adding an adapter, removing an adapter for a running virtual machine is performed the same way as adding one:

  1. Start on the Settings dialog for the virtual machine. Switch to the tab for the adapter that you wish to remove:
    harn_addedadapter
  2. Click the Remove button.
    harn_removeadapter
  3. The tab for the adapter to be removed will have all of its text crossed out. The dialog items for it will turn gray.
    harn_removeadapterpending
  4. Click OK to remove the adapter and close the dialog or Apply to remove the adapter and leave the dialog open. Click Cancel if you change your mind. For OK or Apply, a prompt will appear with a warning that you’ll probably disrupt network communications:
    harn_removeprompt

Hot Add/Remove of Hyper-V Virtual Adapters for Linux Guests

I didn’t invest a great deal of effort into testing, but this feature works for Linux guests with mixed results. A Fedora guest running on my Windows 10 system was perfectly happy with it:

harn_linux

OpenSUSE Leap… not so much:

harn_noleap

But then, I added another virtual network adapter to my OpenSUSE system. This time, I remembered to connect it to a virtual switch before adding. It liked that much better:

harn_leapon

So, the moral of the story: for Linux guests, always specify a virtual switch when hot adding a virtual network card. Connecting it afterward does not help.

Also notice that OpenSUSE Leap did not ever automatically configure the adapter for DHCP, whereas Fedora did. As I mentioned in the beginning of the article, you might need to give some environments an extra push.

Also, Leap seemed to get upset when I hot removed the adapter:

harn_leapout

To save your eyes, the meat of that message says: “unable to send revoke receive buffer to netvsp”. I don’t know if that’s serious or not. The second moral of this story, then: hot removing network adapters might leave some systems in an inconsistent, unhappy state.

My Thoughts on Hyper-V’s Hot Add/Remove of Network Adapters Feature

Previous versions of Hyper-V did not have this feature and I never missed it. I wasn’t even aware that other hypervisors had it until I saw posts from people scrounging for any tiny excuse to dump hate on Microsoft. Sure, I’ve had a few virtual machines with services that benefited from multiple network adapters. However, I knew of that requirement going in, so I just built them appropriately from the beginning. I suppose that’s a side effect of competent administration. Overall, I find this feature to be a hammer desperately seeking a nail.

That said, it misses the one use that I might have: it doesn’t work for generation 1 VMs. As you know, a generation 1 Hyper-V virtual machine can only PXE boot from a legacy network adapter. The legacy network adapter has poor performance. I’d like to be able to remove that legacy adapter post-deployment without shutting down the virtual machine. That said, it’s very low on my wish list. I’m guessing that we’ll eventually be using generation 2 VMs exclusively, so the problem will handle itself.

During my testing, I did not find any problems at all using this feature with Windows guests. As you can see from the Linux section, things didn’t go quite as well there. Either way, I would think twice about using this feature with production systems. Network disruptions do not always behave exactly as you might think because networks often behave unexpectedly. Multi-homed systems often crank the “strange” factor up somewhere near “haunted”. Multi-home a system and fire up Wireshark. I can almost promise that you’ll see something that you didn’t expect within the first five minutes.

I know that you’re going to use this feature anyway, and that’s fine; that’s why it’s there. I would make one recommendation: before removing an adapter, clear its TCP/IP settings and disconnect it from the virtual switch. That gives the guest operating system a better opportunity to deal with the removal of the adapter on familiar terms.

95 Best Practices for Optimizing Hyper-V Performance

95 Best Practices for Optimizing Hyper-V Performance

We can never get enough performance. Everything needs to be faster, faster, faster! You can find any number of articles about improving Hyper-V performance and best practices, of course, unfortunately, a lot of the information contains errors, FUD, and misconceptions. Some are just plain dated. Technology has changed and experience is continually teaching us new insights. From that, we can build a list of best practices that will help you to tune your system to provide maximum performance.

How to optimize Hyper-V Performance

Philosophies Used in this Article

This article focuses primarily on performance. It may deviate from other advice that I’ve given in other contexts. A system designed with performance in mind will be built differently from a system with different goals. For instance, a system that tries to provide high capacity at a low price point would have a slower performance profile than some alternatives.

  • Subject matter scoped to the 2012 R2 and 2016 product versions.
  • I want to stay on target by listing the best practices with fairly minimal exposition. I’ll expand ideas where I feel the need; you can always ask questions in the comments section.
  • I am not trying to duplicate pure physical performance in a virtualized environment. That’s a wasted effort.
  • I have already written an article on best practices for balanced systems. It’s a bit older, but I don’t see anything in it that requires immediate attention. It was written for the administrator who wants reasonable performance but also wants to stay under budget.
  • This content targets datacenter builds. Client Hyper-V will follow the same general concepts with variable applicability.

General Host Architecture

If you’re lucky enough to be starting in the research phase — meaning, you don’t already have an environment — then you have the most opportunity to build things properly. Making good purchase decisions pays more dividends than patching up something that you’ve already got.

  1. Do not go in blind.
    • Microsoft Assessment and Planning Toolkit will help you size your environment: MAP Toolkit
    • Ask your software vendors for their guidelines for virtualization on Hyper-V.
    • Ask people that use the same product(s) if they have virtualized on Hyper-V.
  2. Stick with logo-compliant hardware. Check the official list: https://www.windowsservercatalog.com/
  3. Most people will run out of memory first, disk second, CPU third, and network last. Purchase accordingly.
  4. Prefer newer CPUs, but think hard before going with bleeding edge. You may need to improve performance by scaling out. Live Migration requires physical CPUs to be the same or you’ll need to enable CPU compatibility mode. If your environment starts with recent CPUs, then you’ll have the longest amount of time to be able to extend it. However, CPUs commonly undergo at least one revision, and that might be enough to require compatibility mode. Attaining maximum performance may reduce virtual machine mobility.
  5. Set a target density level, e.g. “25 virtual machines per host”. While it may be obvious that higher densities result in lower performance, finding the cut-off line for “acceptable” will be difficult. However, having a target VM number in mind before you start can make the challenge less nebulous.
  6. Read the rest of this article before you do anything.

Management Operating System

Before we carry on, I just wanted to make sure to mention that Hyper-V is a type 1 hypervisor, meaning that it runs right on the hardware. You can’t “touch” Hyper-V because it has no direct interface. Instead, you install a management operating system and use that to work with Hyper-V. You have three choices:

Note: Nano Server initially offered Hyper-V, but that functionality will be removed (or has already been removed, depending on when you read this). Most people ignore the fine print of using Nano Server, so I never recommended it anyway.

TL;DR: In absence of a blocking condition, choose Hyper-V Server. A solid blocking condition would be the Automatic Virtual Machine Activation feature of Datacenter Edition. In such cases, the next preferable choice is Windows Server in Core mode.

I organized those in order by distribution size. Volumes have been written about the “attack surface” and patching. Most of that material makes me roll my eyes. No matter what you think of all that, none of it has any meaningful impact on performance. For performance, concern yourself with the differences in CPU and memory footprint. The widest CPU/memory gap lies between Windows Server and Windows Server Core. When logged off, the Windows Server GUI does not consume many resources, but it does consume some. The space between Windows Server Core and Hyper-V Server is much tighter, especially when the same features/roles are enabled.

One difference between Core and Hyper-V Server is the licensing mechanism. On Datacenter Edition, that does include the benefit of Automatic Virtual Machine Activation (AVMA). That only applies to the technological wiring. Do not confuse it with the oft-repeated myth that installing Windows Server grants guest licensing privileges. The legal portion of licensing stands apart; read our eBook for starting information.

Because you do not need to pay for the license for Hyper-V Server, it grants one capability that Windows Server does not: you can upgrade at any time. That allows you to completely decouple the life cycle of your hosts from your guests. Such detachment is a hallmark of the modern cloud era.

If you will be running only open source operating systems, Hyper-V Server is the natural choice. You don’t need to pay any licensing fees to Microsoft at all with that usage. I don’t realistically expect any pure Linux shops to introduce a Microsoft environment, but Linux-on-Hyper-V is a fantastic solution in a mixed-platform environment. And with that, let’s get back onto the list.

Management Operating System Best Practices for Performance

  1. Prefer Hyper-V Server first, Windows Server Core second
  2. Do not install any software, feature, or role in the management operating system that does not directly aid the virtual machines or the management operating system. Hyper-V prioritizes applications in the management operating system over virtual machines. That’s because it trusts you; if you are running something in the management OS, it assumes that you really need it.
  3. Do not log on to the management operating system. Install the management tools on your workstation and manipulate Hyper-V remotely.
  4. If you must log on to the management operating system, log off as soon as you’re done.
  5. Do not browse the Internet from the management operating system. Don’t browse from any server, really.
  6. Stay current on mainstream patches.
  7. Stay reasonably current on driver versions. I know that many of my peers like to install drivers almost immediately upon release, but I can’t join that camp. While it’s not entirely unheard of for a driver update to bring performance improvements, it’s not common. With all of the acquisitions and corporate consolidations going on in the hardware space — especially networking — I feel that the competitive drive to produce quality hardware and drivers has entered a period of decline. In simple terms, view new drivers as a potential risk to stability, performance, and security.
  8. Join your hosts to the domain. Systems consume less of your time if they answer to a central authority.
  9. Use antivirus and intrusion prevention. As long you choose your anti-malware vendor well and the proper exclusions are in place, performance will not be negatively impacted. Compare that to the performance of a compromised system.
  10. Read through our article on host performance tuning.

Leverage Containers

In the “traditional” virtualization model, we stand up multiple virtual machines running individual operating system environments. As “virtual machine sprawl” sets in, we wind up with a great deal of duplication. In the past, we could justify that as a separation of the environment. Furthermore, some Windows Server patches caused problems for some software but not others. In the modern era, containers and omnibus patch packages have upset that equation.

Instead of building virtual machine after virtual machine, you can build a few virtual machines. Deploy containers within them. Strategies for this approach exceed the parameters of this article, but you’re aiming to reduce the number of disparate complete operating system environments deployed. With careful planning, you can reduce density while maintaining a high degree of separation for your services. Fewer kernels are loaded, fewer context switches occur, less memory contains the same code bits, fewer disk seeks to retrieve essentially the same information from different locations.

  1. Prefer containers over virtual machines where possible.

CPU

You can’t do a great deal to tune CPU performance in Hyper-V. Overall, I count that among my list of “good things”; Microsoft did the hard work for you.

  1. Follow our article on host tuning; pay special attention to C States and the performance power settings.
  2. For Intel chips, leave hyperthreading on unless you have a defined reason to turn it off.
  3. Leave NUMA enabled in hardware. On your VMs’ property sheet, you’ll find a Use Hardware Topology button. Remember to use that any time that you adjust the number of vCPUs assigned to a virtual machine or move it to a host that has a different memory layout (physical core count and/or different memory distribution).
    best pratices for optimizing hyper-v performance - settings NUMA configuration
  4. Decide whether or not to allow guests to span NUMA nodes (the global host NUMA Spanning setting). If you size your VMs to stay within a NUMA node and you are careful to not assign more guests than can fit solidly within each NUMA node, then you can increase individual VM performance. However, if the host has trouble locking VMs into nodes, then you can negatively impact overall memory performance. If you’re not sure, just leave NUMA at defaults and tinker later.
  5. For modern guests, I recommend that you use at least two virtual CPUs per virtual machine. Use more in accordance with the virtual machine’s performance profile or vendor specifications. This is my own personal recommendation; I can visibly detect the response difference between a single vCPU guest and a dual vCPU guest.
  6. For legacy Windows guests (Windows XP/Windows Server 2003 and earlier), use 1 vCPU. More will likely hurt performance more than help.
  7. Do not grant more than 2 vCPU to a virtual machine without just cause. Hyper-V will do a better job reducing context switches and managing memory access if it doesn’t need to try to do too much core juggling. I’d make exceptions for very low-density hosts where 2 vCPU per guest might leave unused cores. At the other side, if you’re assigning 24 cores to every VM just because you can, then you will hurt performance.
  8. If you are preventing VMs from spanning NUMA nodes, do not assign more vCPU to a VM than you have matching physical cores in a NUMA node (usually means the number of cores per physical socket, but check with your hardware manufacturer).
  9. Use Hyper-V’s priority, weight, and reservation settings with great care. CPU bottlenecks are highly uncommon; look elsewhere first. A poor reservation will cause more problems than it solves.

Memory

I’ve long believed that every person that wants to be a systems administrator should be forced to become conversant in x86 assembly language, or at least C. I can usually spot people that have no familiarity with programming in such low-level languages because they almost invariably carry a bizarre mental picture of how computer memory works. Fortunately, modern memory is very, very, very fast. Even better, the programmers of modern operating system memory managers have gotten very good at their craft. Trying to tune memory as a systems administrator rarely pays dividends. However, we can establish some best practices for memory in Hyper-V.

  1. Follow our article on host tuning. Most importantly, if you have multiple CPUs, install your memory such that it uses multi-channel and provides an even amount of memory to each NUMA node.
  2. Be mindful of operating system driver quality. Windows drivers differ from applications in that they can permanently remove memory from the available pool. If they do not properly manage that memory, then you’re headed for some serious problems.
  3. Do not make your CSV cache too large.
  4. For virtual machines that will perform high quantities of memory operations, avoid dynamic memory. Dynamic memory disables NUMA (out of necessity). How do you know what constitutes a “high volume”? Without performance monitoring, you don’t.
  5. Set your fixed memory VMs to a higher priority and a shorter startup delay than your Dynamic Memory VMs. This ensures that they will start first, allowing Hyper-V to plot an optimal NUMA layout and reduce memory fragmentation. It doesn’t help a lot in a cluster, unfortunately. However, even in the best case, this technique won’t yield many benefits.
  6. Do not use more memory for a virtual machine than you can prove that it needs. Especially try to avoid using more memory than will fit in a single NUMA node.
  7. Use Dynamic Memory for virtual machines that do not require the absolute fastest memory performance.
  8. For Dynamic Memory virtual machines, pay the most attention to the startup value. It sets the tone for how the virtual machine will be treated during runtime. For virtual machines running full GUI Windows Server, I tend to use a startup of either 1 GB or 2 GB, depending on the version and what else is installed.
  9. For Dynamic Memory VMs, set the minimum to the operating system vendor’s stated minimum (512 MB for Windows Server). If the VM hosts a critical application, add to the minimum to ensure that it doesn’t get choked out.
  10. For Dynamic Memory VMs, set the maximum to a reasonable amount. You’ll generally discover that amount through trial and error and performance monitoring. Do not set it to an arbitrarily high number. Remember that, even on 2012 R2, you can raise the maximum at any time.

Check the CPU section for NUMA guidance.

Networking

In the time that I’ve been helping people with Hyper-V, I don’t believe that I’ve seen anyone waste more time worrying about anything that’s less of an issue than networking. People will read whitepapers and forums and blog articles and novels and work all weekend to draw up intricately designed networking layouts that need eight pages of documentation. But, they won’t spend fifteen minutes setting up a network utilization monitor. I occasionally catch grief for using MRTG since it’s old and there are shinier, bigger, bolder tools, but MRTG is easy and quick to set up. You should know how much traffic your network pushes. That knowledge can guide you better than any abstract knowledge or feature list.

That said, we do have many best practices for networking performance in Hyper-V.

  1. Follow our article on host tuning. Especially pay attention to VMQ on gigabit and separation of storage traffic.
  2. If you need your network to go faster, use faster adapters and switches. A big team of gigabit won’t keep up with a single 10 gigabit port.
  3. Use a single virtual switch per host. Multiple virtual switches add processing overhead. Usually, you can get a single switch to do whatever you wanted multiple switches to do.
  4. Prefer a single large team over multiple small teams. This practice can also help you to avoid needless virtual switches.
  5. For gigabit, anything over 4 physical ports probably won’t yield meaningful returns. I would use 6 at the outside. If you’re using iSCSI or SMB, then two more physical adapters just for that would be acceptable.
  6. For 10GbE, anything over 2 physical ports probably won’t yield meaningful returns.
  7. If you have 2 10GbE and a bunch of gigabit ports in the same host, just ignore the gigabit. Maybe use it for iSCSI or SMB, if it’s adequate for your storage platform.
  8. Make certain that you understand how the Hyper-V virtual switch functions. Most important:
    • You cannot “see” the virtual switch in the management OS except with Hyper-V specific tools. It has no IP address and no presence in the Network and Sharing Center applet.
    • Anything that appears in Network and Sharing Center that you think belongs to the virtual switch is actually a virtual network adapter.
    • Layer 3 (IP) information in the host has no bearing on guests — unless you create an IP collision
  9. Do not create a virtual network adapter in the management operating system for the virtual machines. I did that before I understood the Hyper-V virtual switch, and I have encountered lots of other people that have done it. The virtual machines will use the virtual switch directly.
  10. Do not multi-home the host unless you know exactly what you are doing. Valid reasons to multi-home:
    • iSCSI/SMB adapters
    • Separate adapters for cluster roles. e.g. “Management”, “Live Migration”, and “Cluster Communications”
  11. If you multi-home the host, give only one adapter a default gateway. If other adapters must use gateways, use the old route command or the new New-NetRoute command.
  12. Do not try to use internal or private virtual switches for performance. The external virtual switch is equally fast. Internal and private switches are for isolation only.
  13. If all of your hardware supports it, enable jumbo frames. Ensure that you perform validation testing (i.e.: ping storage-ip -f -l 8000)
  14. Pay attention to IP addressing. If traffic needs to locate an external router to reach another virtual adapter on the same host, then traffic will traverse the physical network.
  15. Use networking QoS if you have identified a problem.
    • Use datacenter bridging, if your hardware supports it.
    • Prefer the Weight QoS mode for the Hyper-V switch, especially when teaming.
    • To minimize the negative side effects of QoS, rely on limiting the maximums of misbehaving or non-critical VMs over trying to guarantee minimums for vital VMs.
  16. If you have SR-IOV-capable physical NICs, it provides the best performance. However, you can’t use the traditional Windows team for the physical NICs. Also, you can’t use VMQ and SR-IOV at the same time.
  17. Switch-embedded teaming (2016) allows you to use SR-IOV. Standard teaming does not.
  18. If using VMQ, configure the processor sets correctly.
  19. When teaming, prefer Switch Independent mode with the Dynamic load balancing algorithm. I have done some performance testing on the types (near the end of the linked article). However, a reader commented on another article that the Dynamic/Switch Independent combination can cause some problems for third-party load balancers (see comments section).

Storage

When you need to make real differences in Hyper-V’s performance, focus on storage. Storage is slow. The best way to make storage not be slow is to spend money. But, we have other ways.

  1. Follow our article on host tuning. Especially pay attention to:
    • Do not break up internal drive bays between Hyper-V and the guests. Use one big array.
    • Do not tune the Hyper-V partition for speed. After it boots, Hyper-V averages zero IOPS for itself. As a prime example, don’t put Hyper-V on SSD and the VMs on spinning disks. Do the opposite.
    • The best ways to get more storage speed is to use faster disks and bigger arrays. Almost everything else will only yield tiny differences.
  2. For VHD (not VHDX), use fixed disks for maximum performance. Dynamically-expanding VHD is marginally, but measurably, slower.
  3. For VHDX, use dynamically-expanding disks for everything except high-utilization databases. I receive many arguments on this, but I’ve done the performance tests and have years of real-world experience. You can trust that (and run the tests yourself), or you can trust theoretical whitepapers from people that make their living by overselling disk space but have perpetually misplaced their copy of diskspd.
  4. Avoid using shared VHDX (2012 R2) or VHDS (2016). Performance still isn’t there. Give this technology another maturation cycle or two and look at it again.
  5. Where possible, do not use multiple data partitions in a single VHD/X.
  6. When using Cluster Shared Volumes, try to use at least as many CSVs as you have nodes. Starting with 2012 R2, CSV ownership will be distributed evenly, theoretically improving overall access.
  7. You can theoretically improve storage performance by dividing virtual machines across separate storage locations. If you need to make your arrays span fewer disks in order to divide your VMs’ storage, you will have a net loss in performance. If you are creating multiple LUNs or partitions across the same disks to divide up VMs, you will have a net loss in performance.
  8. For RDS virtual machine-based VDI, use hardware-based or Windows’ Hyper-V-mode deduplication on the storage system. The read hits, especially with caching, yield positive performance benefits.
  9. The jury is still out on using host-level deduplication for Windows Server guests, but it is supported with 2016. I personally will be trying to place Server OS disks on SMB storage deduplicated in Hyper-V mode.
  10. The slowest component in a storage system is the disk(s); don’t spend a lot of time worrying about controllers beyond enabling caching.
  11. RAID-0 is the fastest RAID type, but provides no redundancy.
  12. RAID-10 is generally the fastest RAID type that provides redundancy.
  13. For Storage Spaces, three-way mirror is fastest (by a lot).
  14. For remote storage, prefer MPIO or SMB multichannel over multiple unteamed adapters. Avoid placing this traffic on teamed adapters.
  15. I’ve read some scattered notes that say that you should format with 64 kilobyte allocation units. I have never done this, mostly because I don’t think about it until it’s too late. If the default size hurts anything, I can’t tell. Someday, I’ll remember to try it and will update this article after I’ve gotten some performance traces. If you’ll be hosting a lot of SQL VMs and will be formatting their VHDX with 64kb AUs, then you might get more benefit.
  16. I still don’t think that ReFS is quite mature enough to replace NTFS for Hyper-V. For performance, I definitely stick with NTFS.
  17. Don’t do full defragmentation. It doesn’t help. The minimal defragmentation that Windows automatically performs is all that you need. If you have some crummy application that makes this statement false, then stop using that application or exile it to its own physical server. Defragmentation’s primary purpose is to wear down your hard drives so that you have to buy more hard drives sooner than necessary, which is why employees of hardware vendors recommend it all the time. If you have a personal neurosis that causes you pain when a disk becomes “too” fragmented, use Storage Live Migration to clear and then re-populate partitions/LUNs. It’s wasted time that you’ll never get back, but at least it’s faster. Note: All retorts must include verifiable and reproducible performance traces, or I’m just going to delete them.

Clustering

For real performance, don’t cluster virtual machines. Use fast internal or direct-attached SSDs. Cluster for redundancy, not performance. Use application-level redundancy techniques instead of relying on Hyper-V clustering.

In the modern cloud era, though, most software doesn’t have its own redundancy and host clustering is nearly a requirement. Follow these best practices:

  1. Validate your cluster. You may not need to fix every single warning, but be aware of them.
  2. Follow our article on host tuning. Especially pay attention to the bits on caching storage. It includes a link to enable CSV caching.
  3. Remember your initial density target. Add as many nodes as necessary to maintain that along with sufficient extra nodes for failure protection.
  4. Use the same hardware in each node. You can mix hardware, but CPU compatibility mode and mismatched NUMA nodes will have at least some impact on performance.
  5. For Hyper-V, every cluster node should use a minimum of two separate IP endpoints. Each IP must exist in a separate subnet. This practice allows the cluster to establish multiple simultaneous network streams for internode traffic.
    • One of the addresses must be designated as a “management” IP, meaning that it must have a valid default gateway and register in DNS. Inbound connections (such as your own RDP and PowerShell Remoting) will use that IP.
    • None of the non-management IPs should have a default gateway or register in DNS.
    • One alternative IP endpoint should be preferred for Live Migration. Cascade Live Migration preference order through the others, ending with the management IP. You can configure this setting most easily in Failover Cluster Manager by right-clicking on the Networks node.
    • Further IP endpoints can be used to provide additional pathways for cluster communications. Cluster communications include the heartbeat, cluster status and update messages, and Cluster Shared Volume information and Redirected Access traffic.
    • You can set any adapter to be excluded from cluster communications but included in Live Migration in order to enforce segregation. Doing so generally does not improve performance, but may be desirable in some cases.
    • You can use physical or virtual network adapters to host cluster IPs.
    • The IP for each cluster adapter must exist in a unique subnet on that host.
    • Each cluster node must contain an IP address in the same subnet as the IPs on other nodes. If a node does not contain an IP in a subnet that exists on other nodes, then that network will be considered “partitioned” and the node(s) without a member IP will be excluded from that network.
    • If the host will connect to storage via iSCSI, segregate iSCSI traffic onto its own IP(s). Exclude it/them from cluster communications and Live Migration. Because they don’t participate in cluster communications, it is not absolutely necessary that they be placed into separate subnets. However, doing so will provide some protection from network storms.
  6. If you do not have RDMA-capable physical adapters, Compression usually provides the best Live Migration performance.
  7. If you do have RDMA-capable physical adapters, SMB usually provides the best Live Migration performance.
  8. I don’t recommend spending time tinkering with the metric to shape CSV traffic anymore. It utilizes SMB, so the built-in SMB multi-channel technology can sort things out.

Virtual Machines

The preceding guidance obliquely covers several virtual machine configuration points (check the CPU and the memory sections). We have a few more:

  1. Don’t use Shielded VMs or BitLocker. The encryption and VMWP hardening incur overhead that will hurt performance. The hit is minimal — but this article is about performance.
  2. If you have 1) VMs with very high inbound networking needs, 2) physical NICs >= 10GbE, 3) VMQ enabled, 4) spare CPU cycles, then enable RSS within the guest operating systems. Do not enable RSS in the guest OS unless all of the preceding are true.
  3. Do not use the legacy network adapter in Generation 1 VMs any more than absolutely necessary.
  4. Utilize checkpoints rarely and briefly. Know the difference between standard and “production” checkpoints.
  5. Use time synchronization appropriately. Meaning, virtual domain controllers should not have the Hyper-V time synchronization service enabled, but all other VMs should (generally speaking). The hosts should pull their time from the domain hierarchy. If possible, the primary domain controller should be pulling from a secured time source.
  6. Keep Hyper-V guest services up-to-date. Supported Linux systems can be updated via kernel upgrades/updates from their distribution repositories. Windows 8.1+ and Windows Server 2012 R2+ will update from Windows Update.
  7. Don’t do full defragmentation in the guests, either. Seriously. We’re administering multi-spindle server equipment here, not displaying a progress bar to someone with a 5400-RPM laptop drive so that they feel like they’re accomplishing something.
  8. If the virtual machine’s primary purpose is to run an application that has its own replication technology, don’t use Hyper-V Replica. Examples: Active Directory and Microsoft SQL Server. Such applications will replicate themselves far more efficiently than Hyper-V Replica.
  9. If you’re using Hyper-V Replica, consider moving the VMs’ page files to their own virtual disk and excluding it from the replica job. If you have a small page file that doesn’t churn much, that might cost you more time and effort than you’ll recoup.
  10. If you’re using Hyper-V Replica, enable compression if you have spare CPU but leave it disabled if you have spare network. If you’re not sure, use compression.
  11. If you are shipping your Hyper-V Replica traffic across an encrypted VPN or keeping its traffic within secure networks, use Kerberos. SSL en/decryption requires CPU. Also, the asymmetrical nature of SSL encryption causes the encrypted data to be much larger than its decrypted source.

Monitoring

You must monitor your systems. Monitoring is not and has never been, an optional activity.

  1. Be aware of Hyper-V-specific counters. Many people try to use Task Manager in the management operating system to gauge guest CPU usage, but it just doesn’t work. The management operating system is a special-case virtual machine, which means that it is using virtual CPUs. Its Task Manager cannot see what the guests are doing.
  2. Performance Monitor has the most power of any built-in tool, but it’s tough to use. Look at something like Performance Analysis of Logs (PAL) tool, which understands Hyper-V.
  3. In addition to performance monitoring, employ state monitoring. With that, you no longer have to worry (as much) about surprise events like disk space or memory filling up. I like Nagios, as regular readers already know, but you can select from many packages.
  4. Take periodic performance baselines and compare them to earlier baselines

 

If you’re able to address a fair proportion of points from this list, I’m sure you’ll see a boost in Hyper-V performance. Don’t forget this list is not exhaustive and I’ll be adding to it periodically to ensure it’s as comprehensive as possible however if you think there’s something missing, let me know in the comments below and you may see the number 95 increase!

Get Involved on twitter: #How2HyperV

Get involved on twitter where we will be regularly posting excerpts from this article and engaging the IT community to help each other improve our use of Hyper-V. Got your own Hyper-V tips or tricks for boosting performance? Use the hashtag #How2HyperV when you tweet and share your knowledge with the world!

#How2HyperV Tweets

The Complete Guide to Hyper-V Networking

The Complete Guide to Hyper-V Networking

I frequently write about all sorts of Hyper-V networking topics. I was surprised to learn that we’ve never published a unified article that gives a clear and complete how-to that brings all of these related topics into one resource. We’ll fix that right now.

Understanding the Basics of Hyper-V Networking

We have produced copious amounts of material explaining the various concepts around Hyper-V networking. I want to spend as little time as possible on that here. Comprehension is very important, though, so here’s an index of expository work:

  • How the Hyper-V Virtual Switch Works: If you don’t understand the contents of that article, you will have a very difficult time administering Hyper-V. Read it, and read it again until you have absorbed it. It answers easily 90% of the questions that I receive about Hyper-V networking. If something there doesn’t make sense, ask.
  • The OSI model and Hyper-V: A quick read on the OSI model and a brief introduction to its relevance to Hyper-V. If you’ve been skimming over the terms “layer 2” and “layer 3” because you don’t have a solid understanding of them, read it.
  • Hyper-V and VLANs: That article ties closely to the OSI article. VLANs are a layer 2 technology. Due to common usage, newcomers often confuse them with layer 3 operations. I’m frequently asked about trunking multiple VLANs into a virtual machine, even though I’m fairly certain that most people don’t really want to do that. This article should help you sort out those concepts.
  • Hyper-V and IP: That article also ties closely to the OSI article and contrasts against the VLAN article. It doesn’t contain a great deal of direct Hyper-V knowledge, but it should help fill any of the most serious deficiencies in TCP/IP comprehension.
  • Hyper-V and Link Aggregation (Teaming): That article describes the concepts around NIC teaming and addresses some of the myths that I encounter. The article that you’re reading now will bring you the “how”.
  • Hyper-V and DNS: If I were to compile a list of ridiculously simple technologies that people tend to ridiculously over-complicate, I’d place DNS in the top slot. Hyper-V itself cares nothing about DNS, but its management operating systems and guests care very much. Poor DNS configurations can be blamed for nearly all of the world’s technological ills. You must learn it. It won’t take long.
  • Hyper-V and Binding Order: Lots of administrators spend lots of time wringing their hands over network binding order. Stop. Only the DNS subsystem and one other thing (that I’ve now forgotten about) pay any attention to the binding order. If you get that, then you don’t really need to read the linked article.
  • Hyper-V and Load Balancing Algorithms: The “hows” of load balancing algorithms will be on display in the article that you’re reading. If you want to understand the “what” and the “why”, then follow the link.
  • Hyper-V and MPIO and Teaming for Storage: I see lots of complaints from people that create a switch independent team on a pair of 10GbE pipes that wind back to a storage array with 5x 10,000 RPM disks. They test it with a file copy and don’t understand why they can’t move 20Gbps. Invariably, they blame Hyper-V. If you don’t want to be that guy, the linked article should help.

That should serve as a decent reference on the concepts. If you don’t understand something written below, it’s probably because you don’t understand something linked above.

Contents of this Article

I will demonstrate common PowerShell and, where available, GUI methods for working with:

  • Standard network adapter teaming
  • Hyper-V virtual switch
  • Switch Embedded Teaming
  • Hyper-V virtual adapters

PowerShell or GUI?

Use PowerShell for quick, precise, repeatable, scriptable operations. Use the GUI to do the same amount of work in twice the time following four times as many instructions. I will show all of the PowerShell methods first for the benefit of those that just want to get things done. If you prefer to plod through dozens of GUI screens, scroll to the bottom half of the article. Be aware that many things can’t be done in the GUI.

If you’re just getting started with PowerShell, remember to use tab completion! It makes all the difference!

Creating and Working with Network Adapter Teams for Hyper-V in PowerShell

If you’re interested in Switch Embedded Teaming (Server 2016 only), then look a few headings downward. This section applies to the standard Microsoft teaming methods.

First things first. You need to know which adapters to add to the team. Discover your available adapters:

I’ll use my system for reference. I’ve renamed all of the adapters in my system so that I can recognize them. If your hardware supports Consistent Device Naming, then you’ll likely already have actionable names (like “Slot 4 Port 1”). If not, you’ll need to find your own way to identify adapters. I use my switch’s interface to enable the ports one at a time, identifying the adapters as they switch to Connected status.

Creating and Working with Network Adapter Teams for Hyper-V

The PowerShell cmdlets for networking allow you to use names, indexes, or descriptions to manipulate adapters. The teaming cmdlets only work with names.

Create a Windows Team

Create teams with New-NetLbfoTeam.

I use my demo machines’ “P*L” adapters for Hyper-V teams. One way to create a team for them:

I usually Name my team for the virtual switch that I create on it, but choose any name that you like. The TeamMembers field accepts a comma-separated list of the names of the physical adapters to add to the team. I promised not to go into detail on the options, and I won’t. Just remember that the other parameters and their values are selectable by tab completion. SwitchIndependent is the preferred teaming mode in most cases with LACP being second. I have never seen any compelling reason to use a load balancing algorithm other than Dynamic. Most people will want to use the Dynamic load balancing algorithm as it combines the best of Hyper-V Port mode and the hash mode along with some special features that can relocate traffic dynamically. However, if you will be combining Switch Independent and Dynamic with an external third-party load balancer, I recommend that you read the comment section for helpful warnings from reader Jahn.

To save even more time and space, the cmdlet is smart enough to allow you to use wildcards for the adapter names:

If you want to avoid the prompt for scripting purposes, add the Force parameter.

A Note on the Team NIC

When you create a team, you also create a logical adapter that represents that team. A logical team NIC (often abbreviated as tNIC) works in a conceptually similar fashion to a Hyper-V virtual NIC. You treat it just like you would a physical adapter — give it an IP address, etc. The team determines what to do with your traffic. If you use the cmdlets as shown above, one team NIC will be created and it will have the same name as the team (“vSwitch”, in this case). You can override that name with the TeamNicName parameter.

You can also add more team NICs to a team. For a team that hosts a Hyper-V virtual switch, it’s neither recommended nor supported, although the system will allow it. Additional tNICs must be created in their own VLAN, which hides that VLAN from the team. Also, it’s not documented or clear how additional tNICs affect any QoS settings on a Hyper-V virtual switch.

For the rest of this article, the single automatically-created tNIC will be the only one referenced.

Examine Teams and tNICs

View all teams and their statuses with Get-NetLbfoTeam. You don’t need to supply any parameters. I get more use out of Get-NetLbfoTeamMember, also without parameters.

Remove and Add Team Members

You can easily remove team members if you have the need:

And add them:

Removing an adapter obviously disrupts the traffic on that member, but the team will handle it well. You can add a team member at any time.

Delete a Team

Use Remove-NetLbfoTeam to get rid of a team. You can use the Name parameter to reverse what you’ve done. Since my hosts only ever use a single team, I can do this:

Working with the Hyper-V Virtual Switch

I always use Hyper-V virtual switches and Microsoft teams together, so I have a certain technique. You may choose a different path. Just understand that external switches must be created on an adapter. I will always use the default tNIC. If you’re not teaming, then you’ll pick a single physical NIC. Use Get-NetAdapter as shown in the teaming section above to determine the name of the adapter that you wish to use.

Create a Virtual Switch

Use New-VMSwitch to create a new switch. Most commonly, you’ll want the external type (refer to the articles linked at the beginning if you need an explanation). External switches require you to specify a logical or physical (but not virtual) adapter. You can use its friendly name or its less friendly description. I use the name. In my case, I’m binding to a team’s logical adapter, so, as explained a bit ago, I’ll use the team’s name.

For internal or private, use the SwitchType parameter instead of the NetAdapterName parameter and do not use AllowManagementOS.

Several things to note about the New-VMSwitch cmdlet:

  • New-VMSwitch is not one of the better-developed cmdlets. Usually, when tabbing through available parameters, your options are presented in a sensible order. New-VMSwitch’s parameters are all over the place.
  • The documentation for every version of New-VMSwitch always says that the default MinimumBandwidthMode is Weight. I used to classify this as an error, but it’s been going on for so long I’m starting to wonder if it’s an unfunny inside joke or a deliberate lie. The default is Absolute. Most people won’t ever need QoS, so I don’t know that it has practical importance. However, you can’t change a switch’s QoS mode after it’s been created, so I’d rather tell you this up front.
  • The “AllowManagementOS” parameter’s name is nonsense. What it really means is “immediately create a virtual adapter for the management operating system”. The only reason that I don’t allow it to create one is because it uses the same name for the virtual adapter as the virtual switch. That’s confusing for people that don’t know how all of this works. You can always add virtual adapters later, so the “allow” verb makes no sense whatsoever.

Manipulate a Virtual Switch

Use Set-VMSwitch to make changes to your switch. The cmdlet has so many options that I can’t rationally explain it all. Just scan the parameter list to find what you want. A couple of notes, though:

  • You can’t change the QoS mode of an existing virtual switch.
  • You can switch between External, Internal, and Private types.
    • To go from External to either of the other types: Set-VMSwitch -Name vSwitch -SwitchType Internal. Just use Private instead of Internal if you want that switch type.
    • To from Private or Internal to External: Set-VMSwitch -Name vSwitch -NetAdapterName vSwitch. You’d also use this format to move a virtual switch from one physical/logical network adapter to another.
  • You can’t rename a virtual switch with this cmdlet. Use Rename-VMSwitch.

Remove a Virtual Switch

Appropriately enough, Remove-VMSwitch removes a virtual switch.

You can remove all virtual switches in one shot:

When a switch is removed, virtual NICs on VMs are disconnected. Virtual NICs for the management OS are destroyed.

Speaking of virtual NICs, that’s the next thing you care about if you’re using a standard virtual switch. I’ll explain them after the Switch Embedded Team section.

Working with Hyper-V Switch Embedded Teams

Server 2016 adds Switch Embedded Teaming. If you’re planning to create a team of gigabit adapters, then I recommend that you use the traditional teaming method outlined above. I wrote an article explaining why.

Create a Switch Embedded Team (SET)

Use the familiar New-VMSwitch to set it up, but add the EnableEmbeddedTeaming option. Two other options not shown in the following are EnableIov and EnablePacketDirect.

The documentation continues to be wrong on MinimumBandwidthMode. If you don’t specify otherwise, you get Absolute. Prefer Weight.

Use EnableIov if, and only if, you have 10GbE adapters that support it. I cannot find any details on Packet Direct anywhere. Everyone just repeats that it provides a low-latency connection that bypasses the virtual switch. A few sources add that it will force Hyper-V Port load balancing mode. My hardware doesn’t support it, so I can’t test it. I assume that it only works on 10GbE and probably only with SR-IOV.

Once a SET has been created, you view it with both Get-VMSwitch and Get-VMSwitchTeam. For whatever reason, they decided that the output should include the difficult-to-read interface descriptions instead of names like Get-NetLbfoTeam. You can see the adapter names with something like this:

The SET cmdlets have no analog for Get-NetLbfoTeamMember.

SET does not expose a logical adapter to Windows the way that LBFO does.

Manipulate a Switch Embedded Team

You can change the members and the load balancing mode for a SET using Set-VMSwitchTeam.

Add and Remove SET Members

Instead of Set-VMSwitchTeam, you can use Add-VMSwitchTeamMember and Remove-VMSwitchTeamMember.

Remove a SET

Use Remove-VMSwitch to remove a SET. There is no Remove-VMSwitchTeam cmdlet.

Working with Virtual Network Adapters

You can attach virtual network adapters (vNICs) to the management operating system or virtual machines. You’ll most commonly use them with virtual machines, but you’ll also usually do less work with them. Their default settings tend to be sufficient and you can work with them through their owning virtual machine’s GUI property pages.

For almost every vNIC-related cmdlet, you must indicate whether you’re working with a management OS vNIC or a VM’s vNIC. Do this with the ManagementOS switch parameter or by supplying a value for either the VM or the VMName parameters. If you have a vNIC object, such as the one output by Get-VMNetworkAdapter, then you can pipe it to most of the vNIC cmdlets or provide it as the VMNetworkAdapter parameter. You won’t need to specify any of the other identifying parameters, including those previously mentioned in this paragraph, when you provide the vNIC object.

View a Virtual Network Adapter

The simple act of creating a virtual machine or virtual switch with AllowManagementOS set, creates a vNIC. To view them all:

Ordinarily, we give descriptive names to management OS vNICs, especially when we use more than one. If you didn’t specify AllowManagementOS, then you’ll have a vNIC with the same name as your vSwitch.

Each management OS vNIC will appear in the Network Connections applet and Get-NetAdapter with the format vEthernet (vNICName). Avoid confusion by changing the default vNIC’s name (shown in a bit). Many newcomers believe that this vNIC is the virtual switch because of that name. You cannot “see” the virtual switch anywhere except in Hyper-V-specific management tools.

Ordinarily, we leave the default name of “Network Adapter” for virtual machine vNICs. New in 2016, changes to a guest’s vNIC name will appear in the guest operating system if it supports Consistent Device Naming (CDN).

Manipulate a Virtual Network Adapter

Use Set-VMNetworkAdapter to change vNIC settings. As you can see, this cmdlet is quite busy; I could write multiple full-length articles on various parameter groups. Settings categories available with this command:

  • Quality of service (Qos)
  • Security (MAC spoofing, router guard, DHCP guard, storm)
  • Replica
  • In-guest teaming
  • Performance (VMQ, IOV, vRSS, Packet Direct)

You need a different cmdlet for VLAN manipulation, though.

Manipulate Virtual Network Adapter VLANs

Use Set-VMNetworkAdapterVlan for all things VLAN on vNICs.

To place a management OS vNIC into a VLAN:

Remember that the VlanId parameter requires the Access parameter.

Also remember that there is no such thing as “VLAN 0”. For some unknown reason, the cmdlet will accept it and assign the adapter to VLAN 0, but strange things might happen. Usually, it’s just that you can’t get traffic in or out of the adapter. If you want to clear the adapter’s VLAN, don’t use VLAN 0. Use Untagged:

I’m not going to cover trunking or private VLANs. Trunking is very advanced and I don’t think more than 5 percent of the people that have asked me how to do it really wanted to do it. If you want a single virtual machine to exist in multiple VLANs, add virtual adapters and assign individual VLANs. Private VLANs require you to work with PrimaryVlanId, SecondaryVlanId, SecondaryVlanIdList, Promiscuous, Community, and Isolated as necessary. If you need to use private VLANs, then you or your networking engineer should already understand each of these terms and intuitively understand how to use the parameters.

Since we’re commonly asked, the Promiscuous parameter on Set-VMNetworkAdapterVlan does not have anything to do with accepting or participating in all passing layer 2 traffic. It is only for private VLANs.

Adding and Removing Virtual Network Adapters

Use Add-VMNetworkAdapter and Remove-VMNetworkAdapter for their respective tasks.

Connecting and Disconnecting Virtual Network Adapters to/from Virtual Switches

These cmdlets only work for virtual machine vNICs. You cannot dis/connect management OS vNICs; you can only add or remove them.

Connect always works. You do not need to disconnect an adapter from its current virtual switch to connect it to a new one. If you want to connect all of a VM’s vNICs to the same switch, specify only the virtual machine in VMName.

If you provide the Name parameter, then only that vNIC will be altered:

These two cmdlets do not provide a VM parameter. It is possible for two virtual machines to have the same name. If you need to discern between two VMs with the same name, use the pipeline and filter from other cmdlets:

Use Disconnect-VMNetworkAdapter the same way, leaving off the SwitchName parameter.

VLAN information is preserved across dis/connects.

Other vNIC Settings

I did not touch on the entire range of possible vNIC cmdlets or their settings. You can go to the root 2016 Hyper-V PowerShell page and view all available cmdlets. Search the page for adapter, and you’ll find many hits.

Using the GUI for Hyper-V Networking

The GUI lags dramatically behind PowerShell for most things related to Hyper-V. I doubt any category shows that as strongly as networking. So, whether you (or I) like it or not, using the GUI for Hyper-V network qualifies as “beginner mode”. Most of the things that I showed you above cannot be done in the GUI at all. So, unless you’re managing a single host with a single network adapter, the GUI will probably not help you much.

The following sections show you the few things that you can do in the GUI.

Working with Windows Teams

The GUI does allow you some decent capability when working with Windows teams.

Create a Windows Team

You can use the GUI to create teams on Server 2012 and later. You can find the applet in Server Manager on the Local Server tab.

Using the GUI for Hyper-V Networking

You can also run lbfoadmin.exe from the Run window or an elevated prompt.

Once open, click the Tasks drop-down in the Teams section. Click New Team.

Tasks drop-down in the Teams section

You’ll get the NIC Teaming/New team dialog, where you’ll need to fill out most fields:

NIC Teaming/New team

Manipulate a Team

To make changes to your team later, just return to the same screens and dialogs using the same methods as you used to create the team.

Manipulate a Team

Delete a Team

To delete a team, use the Delete function in the same place on the main lbfoadmin screen where you found the New Team function. Make sure to highlight the team that you want to delete, first.

Delete a Team

Working with the Hyper-V Virtual Switch

The GUI provides very limited ability to work with Hyper-V virtual switches. You can’t configure QoS (except on vNICs) and it allows nearly nothing to be done for management OS vNICs.

Create a Hyper-V Virtual Switch

When using the Add Roles wizard to enable Hyper-V, you can create a virtual switch. I won’t cover that. If you’re looking at that screen, wondering what to do, I recommend that you skip it and follow the PowerShell directions above. If you simply must use a GUI, then wait until after the role finishes installing and create one using Hyper-V Manager.

To create a new virtual switch in Hyper-V Manager:

  1. Right-click the host in Hyper-V Manager and click Virtual Switch Manager. Alternatively, you’ll find this same menu at the far right of the main screen under Actions.
    Working with the Hyper-V Virtual Switch
  2. At the left of the dialog, highlight New virtual network switch.
    Create a Hyper-V Virtual Switch
  3. On the right, choose the type of switch that you want to create. I’m not entirely sure why it even asks because you can pick anything you want once you click Create Virtual Switch.
    Create a Hyper-V Virtual Switch Type
  4. The creation screen itself is very busy. I’ll tackle that in a moment. First, look to the left of the dialog at the blue text. It’s a new entry named New Virtual Switch. It represents what you’re working on now. If you change the name, you’ll see this list item change as well. You can use Apply to make changes and continue working without closing the dialog. You can even add another switch before you accept this one.
    New Virtual Switch

Now for the new switch screen. Look after the screenshot for an explanation of the items:

Virtual Switch properties - Hyper-V Networking

First item: name your switch.

I would skip the notes field, especially in a failover cluster.

For Connection Type, you’re decided between External, Internal, and Private. That’s why I don’t understand why it asked you on the initial dialog. If you choose External, you’ll need to pick a logical or physical adapter for binding. Unfortunately, you can only see the fairly useless adapter description fields. Look in the Network Connections applet to determine which is which. This right here is one of the primary reasons I like switch creation in PowerShell better.

Remember that the IOV setting is permanent.

I despise the item here called Allow management operating system to share this network adapter. That description has absolutely no relation to what the checkbox does. If you check it, it will automatically create a virtual NIC in the management OS for this virtual switch and give it the same name as the virtual switch. That’s all it does. There is no “sharing”, and there is no permanent allowing or disallowing going on.

The VLAN ID section ties to the nonsensical “Allow…” field. If you let the system create a management OS vNIC for you, then you can use this to give it a VLAN ID.

You can use the Remove button if you decide that you don’t want to create the virtual switch after all. Cancel would work, too.

Where’s the QoS? Oh, you can’t set the QoS mode for a virtual switch using the GUI. PowerShell only. If you use this screen to create a virtual switch, it will use the Absolute QoS mode. Forever. Another reason to choose PowerShell.

Manipulate a Virtual Switch

To make changes to a virtual switch, follow the exact steps that you did to create one, except choose the existing virtual switch at the left of the Virtual Switch Manager dialog. Of course, you can’t change much, but there it is.

Remove a Virtual Switch

Retrace your creation steps. Select the virtual switch at the left of the Virtual Switch Manager screen. Click the Remove button at the bottom right.

Working with Hyper-V Switch Embedded Teams

You can’t use the GUI to work with Hyper-V SET. PowerShell-only.

You can use the Virtual Switch Manager as described previously to remove one, though.

Working with Hyper-V Virtual Network Adapters

The GUI provides passably decent ability to work with vNICs — for guests. The only place that you can do anything with management OS vNICs is on that virtual switch creation screen. You can add or remove exactly one vNIC and you can set or remove its VLAN. You can’t use the GUI to work with two or more management OS vNICs. In fact, if you use PowerShell to add a second management OS vNIC, all related items in the dialog are grayed out and unusable.

But, for virtual machines, the GUI exposes most functionality.

Manipulate Virtual Network Adapters on Virtual Machines

In Hyper-V Manager or Failover Cluster Manager, open up the Settings dialog for the virtual machine to work with. On the left, you can find the vNIC that you want to work with. Highlight it, and the page will switch to its configuration screen. In the following screenshot, I’ve also expanded the vNIC so that you can see its subtabs, Hardware Acceleration and Advanced Features.

Manipulate Virtual Network Adapters on Virtual Machines

On this screen, you can change the virtual switch this adapter connects to, or disconnect it. You can change or remove its VLAN. You can set its QoS. The numbers here are given in Absolute since that’s the default. It doesn’t change if your switch uses Weight mode. I would use PowerShell for that. You can also Remove the vNIC here.

The Hardware Acceleration subtab:

Hardware Acceleration

Here, you can change:

  • If a VMQ can be assigned to this vNIC. The host’s adapters must support VMQ and a queue must be available for this checkbox to have any effect.
  • IPSec task offloading. If the host’s physical adapter supports IPSec task offloading and has sufficient resources, the guest can offload IPSec tasks to the hardware.
  • An SR-IOV virtual function can be assigned to this NIC. The host’s adapters and motherboard must support IOV, it must be enabled on the adapter and in BIOS, the virtual switch must either be unteamed or on a SET, and a virtual function must be available for this checkbox to have any effect.

The Advanced Features subtab:

Advanced Features

Note that this screen scrolls, and I didn’t capture it all.

Here, you can change:

  • MAC address, mode and address both
  • Whether or not the guest can spoof the MAC
  • If the guest is prevented from receiving DHCP discover/request frames
  • If the guest is prevented from receiving router discovery packets
  • If a failover cluster will move the guest if it loses network connectivity (Protected network)
  • If the vNIC’s traffic is mirrored to another vNIC. This feature seems to have troubles, FYI.
  • If teaming is allowed in the guest. The guest requires at least two vNICs and the virtual switch must be placed on a team or SET for this to function.
  • The Device naming switch allows the name of the vNIC to be propagated into the guest where an OS that supports Consistent Device Naming (CDN) can use it. Note that this is disabled by default, and the GUI doesn’t allow you to rename the vNIC. Use PowerShell for that.

Remove a Virtual Network Adapter

To remove a vNIC from a guest, find its tab in the VM’s settings dialog in Hyper-V Manager or Failover Cluster Manager. Use the Remove button at the bottom right. You’ll find a screenshot above in the Manipulate Virtual Network Adapters on Virtual Machines section.

 

Note: This guide will be periodically updated to make sure it covers all possible Hyper-V Networking problems. If you think I’ve missed anything please let me know in the comments below.

How to Optimize Hyper-V Performance for Dell PowerEdge T20

How to Optimize Hyper-V Performance for Dell PowerEdge T20

 

A little while back, we published an eBook detailing how to build an inexpensive Hyper-V cluster. At that price point, you’re not going to find anything that breaks performance records. Such a system could meet the needs of a small business, though. For those of you lucky enough to have a more substantial budget, it also works well as a cheap test lab. Whatever your usage, the out-of-box performance can be improved.

The steps in this article were written using the hardware in the previously linked eBook. If you have a Dell T20 that uses a different build, you may not have access to the same options. You may also need to look elsewhere for guidance on configuring additional hardware that I do not have.

A little upfront note: Never expect software or tweaks to match better hardware. If you expect a few switches and tips to turn a T20 into competition for a latest generation PowerEdge R-series, you will leave disappointed. I am always amazed by people that buy budget hardware and then get upset because it acts like budget hardware. If you need much better performance, break out your wallet and buy better hardware.

Step 1: Disable C-States

The number one thing you should always do on all systems to improve Hyper-V performance: disable C-States. You make that change in the system’s BIOS. The T20’s relevant entry appears below. Just clear the box.

t20perf_cstates

I also recommend that you disable SpeedStep, although you probably won’t gain much by doing so.

Step 2: Update Drivers

I know, I know, updating drivers is the oldest of all so-called “performance enhancement” cliches. Bear with me, though. All of the hardware works just fine with Windows default drivers, but the drivers unlock some options that you’ll need.

Start at https://support.dell.com. You’ll be asked for the system’s service tag. At an elevated PowerShell prompt, enter gwmi win32_bios and look at the SerialNumber line:

t20perf_servicetag

Highlight and press [Enter] to copy it to the clipboard.

Select the Drivers and Downloads tab, then locate the Change OS link so that you can select the correct operating system. Dell periodically changes their support site, so you may something different, but these named options have been the same for a while:

t20perf_driversystem

Items that you want:

  • BIOS (reboots without asking; stop your VMs first)
  • Chipset
  • Intel(R) Management Engine Components Installer
  • Intel Rapid Storage Technology Driver and Management Console
  • Intel Rapid Storage Technology F6 Driver

After gathering those files, go to Intel’s support site: https://downloadcenter.intel.com/.

This site also changes regularly. What I did was search for the “I217-LM”. On its list of downloads, I found the Intel Ethernet Adapter Connections CD. That includes drivers for just about every Intel network adapter in existence. If you have the system build that I described in the eBook, this file will update the onboard adapter and the add-in PRO/1000 PTs (and any other Intel network adapters that you might have chosen).

If you’re targeting a GUI-less system, unblock the files. An example:

If you prefer the mouse, then you can use each item’s individual property dialog instead.

Also make sure that you use a GUI system to unzip the Intel CD prior to attempting to install on a GUI-less system.

I’m sure you can install drivers without my help. Do that and read on.

Step 3: Networking Performance Tweaks

Three things you want to do for networking:

  1. Enable jumbo frames for storage adapters
  2. Disable power management
  3. Disable VMQ on any team adapters

Enabling Jumbo Frames

First, make sure that jumbo frames are enabled on your physical switch. It’s always OK for a system to use smaller frames on equipment that has larger frames enabled. The other way around usually just causes excessive fragmentation. That hurts performance, but things still work. Sometimes, it causes Ethernet frames to never be delivered. Always configure your switch first. Many require a power cycle for the change to take effect.

Once jumbo frames are set on your switch, make the change on the T20’s physical adapters. You can make the change in the GUI or in PowerShell.

Enabling Jumbo Frames via the GUI

  1. In Network Connections, access an Intel adapter’s property sheet.
  2. Click the Configure button.
  3. Switch to the Advanced tab.
  4. Set Jumbo Packet to its highest number; usually 9014.

When you install the Intel network drivers and management pack, the I217-LM driver page will look like the following:

t20perf_i217jumbo

Intel adapters not under management will look like this:

t20perf_regularjumbo

Enabling Jumbo Frames in PowerShell

PowerShell makes this fast and simple:

Disabling Network Adapter Power Management

Windows likes to turn off network adapters. Unfortunately, it doesn’t always do the best job ensuring that you’re not still using it. You can disable power management using the GUI or PowerShell.

Disabling Network Adapter Power Management in the GUI

Navigate to the adapter’s properties like you did to enable jumbo frames. This time, go to the Power Management tab. For a device under the control of the Intel management system, just uncheck Reduce link speed during system idle.

t20perf_i217speedreduce

For adapters using default drivers, uncheck Allow the computer to turn off this device to save power:

t20perf_regularnetpm

Disabling Network Adapter Power Management in PowerShell

The process is a bit more involved in PowerShell, but I’ve done the hard work for you. Just copy/paste into an elevated PowerShell prompt or run as a script:

Disable VMQ on Team Adapters

None of the adapters included with this system or in the eBook build support VMQ. That’s good because I don’t know of any manufacturers that properly implement VMQ on gigabit adapters. However, if you create a native Microsoft LBFO team, VMQ will be enabled on it. Whether or not it does anything… I don’t know. I do know that I seemed to clear up some strange issues when I disabled it on 2012. So, I’ve been doing it ever since. It’s quick and easy, so even if it doesn’t help, it certainly won’t hurt.

Note: If you are using the build from the eBook, only follow this section on the Hyper-V hosts. The storage server won’t use VMQ anyway.

Disabling VMQ on Team Adapters Using the GUI

Find the team adapter in Network Connections. It should be quite obvious, since the icon shows two physical adapters. Its description field will say Microsoft Network Adapter Multiplexor Driver.

t20perf_teamadapter

Open it up and get into its adapter configuration properties just as you did for the physical adapters above. Switch to the Advanced tab. Find the Virtual Machine Queues entry and set it to Disabled:

t20perf_teamadapterkillvmq

Disabling VMQ on Team Adapters in PowerShell

PowerShell can make short work of this task:

Step 4: Storage Performance Tweaks

The disks in these systems are slow. Nothing will change that. But, we can even out their transfer patterns a bit.

Changing the Disk Cache Mode for the Hyper-V Hosts

The Hyper-V hosts don’t do a great deal of disk I/O. In my personal configuration, I do place my domain controllers locally. However, for any domain these systems could reasonably handle, the domain controllers will perform very little I/O. We’ll enable the read cache on these systems. It will help, but you may not see much improvement due to their normal usage pattern.

Note: I have not attempted any of this on a GUI-less system. If the graphical interface works, you’ll find its exe at: “C:Program FilesIntelIntel(R) Rapid Storage TechnologyIAStorUI.exe”.

Under the Intel Start menu entry, open Intel® Rapid Storage Technology. Switch to the Performance tab. You could disable the Link Power Management. Its not going to help much on the Hyper-V hosts. Change the Cache mode to Read only.

t20perf_hvstoragecache

Changing the Disk Cache Mode for the Storage Host

The storage server does most of the heavy lifting in this build. We can set some stronger caching policies that will help its performance.

Warning: These steps are safe only if you have a battery backup system that will safely shut down the system in the event of a power outage. As shipped, these systems do not have an internal battery backup for the RAID arrays. You can purchase add-on cards that provide that functionality. My system has one external battery that powers all three hosts. However, its USB interface connects only to the storage system. Do not follow these steps for your Hyper-V hosts unless you have a mechanism to gracefully shut them down in a power outage.

Follow the same steps to access the Intel® Rapid Storage Technology‘s Performance tab as you did on the Hyper-V hosts. This time, disable the power management option, enable write-cache buffer flushing, and set the cache mode to Write back:

t20perf_batterystoragecache

Microsoft’s Tuning Guide

At this point, you’ve made the best improvements that you’re likely to get with this hardware. However, Microsoft publishes tuning guides that might give you a bit more.

Access the 2016 tuning guide: https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/hyper-v-server/index

The 2016 guide doesn’t contain very many instructions to follow; it contains a great deal of information. Aside from changing the power plan to High Performance, you won’t find much to do.

The 2012 R2 guide contains more activities: https://msdn.microsoft.com/en-us/library/windows/hardware/dn567657(v=vs.85).aspx. I do not know how many of these settings are still honored in 2016. I do know that any further changes that you make based on this guide involve trade-offs. For instance, you can disable the I/O balancer; that might speed up I/O for one VM that feels slow, but at the cost of allowing storage bottlenecks.

Test

After any performance change, test things out. You shouldn’t expect to see any Earth-shattering improvements. You definitely don’t want things to become worse. If any issues occur, retrace your steps and undo changes until performance returns — if it returns. It’s not uncommon for performance tweaking to uncover failing hardware. It’s best to carry out these changes soon after you spin up your new equipment for that reason.

Testing Jumbo Frames

Verify that jumbo frame works by pinging a target IP connected via physical switch using the following form:

If pings drop (but normal pings go through) or you receive a message that says, “Packet needs to be fragmented but DF set.”, then something along the way does not support jumbo frames.

The “8000” number doesn’t need to be exact, but it must be large enough to ensure that you are sending a jumbo Ethernet frame (somewhere in the 6000s and over). Due to variances in the way that “jumbo” can be calculated, the displayed “9014” will almost never work. Usually, Windows will send an unfragmented ping no larger than 8972 bytes.

Verify Settings After Driver Updates

Some driver updates return settings to defaults. You might lose jumbo frames and power management settings, for instance. It’s tempting to automate driver settings, but network setting changes cause network transmission interrupts. You’re better off performing manual verification.

 

Hyper-V Hot Topics – January

Hyper-V Hot Topics – January

 

Join Andrew Mason from Microsoft (Principal Program Manager on the Nano Server team at Microsoft), and MVP Andy Syrewicze in an AMA webinar on March 16th to discuss Nano Server. Register for the webinar and get answers directly from Andrew!

Hello again everyone! It’s a new year, and January is past us, so that means it’s time for another edition of the Altaro Hyper-V Hot Topics Series!

For those that aren’t aware, this series focuses on interesting links, and useful howtos from the Hyper-V world, from the previous month. So, with that said, let’s dig right into all the cool Hyper-V stuff from January!

1. Bulk Changing Virtual Hard Disk Path

Author: Ben Armstrong

I came across this one during one of my nightly reviews of my twitter feed, and it instantly caught my eye. Mainly because I’ve been in the same situation mentioned in the article and I know many administrators who have been there as well. The use case that Ben is talking about in this article is that of a file movement use case. Let’s say you’ve just XCOPYed a bunch of virtual hard disks from one location to another, how do you quickly fix the pathing for all the affected VMs? If this describes you, you’ll want to take a look. At the very least add it to you bookmarks for a rainy day!

2. Nano Server PowerShell Package Management

Author: Thomas Maurer

One of the most common questions I get about Nano Server is: “how do I manage the installed software packages?” Nano Server can seem foreign to administrators that aren’t familiar with the CLI and especially so if you have very little PowerShell experience. Thomas Maurer has put together a nice little howto on the basics of managing Nano Server Packages with PowerShell. If you’re looking for a quick reference on the different functions and features, this is the link for you!

3. Hyper-V vs. KVM for OpenStack Performance

Author: Ben Armstrong

Another one from Ben Armstrong from the Hyper-V team and it’s a goody, especially if you like OpenStack. For those that aren’t aware, OpenStack is an open source platform that is designed for hosting cloud infrastructure, and it essentially allows you to bring your own hypervisor, including Hyper-V. Ben has included several links in his post here that catalog a full test of performance between Hyper-V and KVM when used for OpenStack. If you’re looking into OpenStack and you’re on the fence as to what Hypervisor to choose, it’s a good performance article to review.

4. System Center VMM 2016 Feature Demos on Channel 9

Author: Microsoft Server and Management Blog

Not everyone is running System Center VMM, but it’s still good to know what it is, and what it’s capabilities are in case you ever need to add those capabilities into your environment. Whether this describes you, or if you’re already running SCVMM, these are good videos to watch during lunch for the next couple of days. This link contains a list of various feature demos for the newest version of SCVMM, and all of said videos are worth a look.

5. What’s New in Windows Server 2016 Networking

Author: OEMTV

With all that’s changed in Networking in Windows Server 2016, I’ve needed a refresher several times since 2016’s release back in October. One of my good friends Keith Mayer was featured on this episode of OEMTV on Microsoft’s Channel 9 website and it’s a good way to get up to speed again on all the new networking stuff in 2016. I’ve embedded the video below for ease of viewing.

6. Deploying Nano Server Using MDT

Author: Michael Niehaus

It’s no secret that deploying Nano Server can be somewhat difficult. For one it’s a vastly different deployment method than what has been used in previous versions/editions of Windows Server, and it involves quite a bit of CLI kung-fu, which can be difficult for new administrators who may not necessarily be used to PowerShell. This article will show you how you can use MDT to take a little bit of the work out of your Nano server deployment and make things a bit easier overall.

Wrap-Up

Well that wraps things up for us this month! As always, if you know of a cool link or howto, that you feel should be in this list, feel free to share in the comments section below!

With that said, we’ll be back next month for another edition of Hyper-V Hot Topics, so stay tuned!

Client Hyper-V in Windows 10

Client Hyper-V in Windows 10

 

Windows 8 introduced the first incarnation of Hyper-V for the desktop. It’s the same core hypervisor as the Hyper-V that ships with the server SKUs, minus a few features. Like its big brother on the server side, Windows 10 brings several new features to the desktop.

What is Client Hyper-V?

Client Hyper-V is an edition of Hyper-V that is geared toward desktop environments that could be thought of as “Hyper-V Lite”. It shares most of Hyper-V’s features and even brings some of its own. Highlights:

  • Type 1 hypervisor: A type 1 hypervisor is a complete kernel and performs direct hardware control. This means that when you enable Hyper-V in Windows 10, the physical hardware boots to Client Hyper-V, not your root Windows 10 installation. Client Hyper-V then starts up your pre-existing root Windows 10 environment as the management operating system. A management operating system is known as the “root partition” or “partition 0” or the “parent partition” in other hypervisors’ terminologies. It is a virtual machine, but it also has the special ability to exert control over the hypervisor. Contrast this with type 2 hypervisors, which are applications that run inside a normal host operating system and do not have direct access to hardware nor any control over the management operating system. Almost all other desktop-oriented hypervisors are type 2.
  • Guest interaction: Interoperability with guest operating systems is a crucial component for a desktop-oriented hypervisor. Client Hyper-V offers:
    • Sharing and mapping of most host hardware
    • Copy/paste of files from host-to-guest and vice versa (supported guests only)
    • Copy/paste of clipboard content from host-to-guest and vice versa (supported guests only)
  • RemoteFX: Windows 10 brings support for some RemoteFX features into Client Hyper-V. Most importantly, the full functionality of your graphics adapter will be made available to guests for both 2D and 3D acceleration.
  • Connected Standby: If your management operating system goes to sleep, your guests will be OK. When you resume, they will be exactly where they left off.
  • Linux guests: Client Hyper-V directly supports the same guest operating systems that Hyper-V does. This does not necessarily exclude other Linux distributions, but your mileage may vary.
  • Fully virtualized environment: That phrase could be taken to mean a great many things, but what I mostly intend to convey is that whether or not a specific operating system is directly supported as a guest does not indicate whether or not it will function. Hyper-V’s virtual machines are complete x86/AMD64 environments. If an operating system would otherwise run in that environment (most importantly, on your physical CPU’s architecture), then it will almost certainly operate under Hyper-V. Without direct support, however, it may run poorly.
  • Secure environment: Client Hyper-V provides the same security offerings as Hyper-V:
    • Secure boot: If Client Hyper-V doesn’t recognize the boot signature in the guest operating system, it won’t start it. This provides solid protection against root kits.
    • Shielded VMs: The topic of Shielded VMs is very large and won’t be covered in detail in this article. Microsoft’s Windows Server blog has decent starter material on the subject. Essentially, if you are concerned that someone copying the files of your virtual machine to their own local machine is of concern, you have options.
  • Storage Live Migration: You can move a virtual machine from one physical storage location to another without taking it offline.
  • Run VMs from remote storage: Your virtual machines can be stored locally, which is the most typical configuration. You can also run virtual machines from SMB and iSCSI storage.
  • Full-screen support: You can run Client Hyper-V guests within a window, allow them to consume an entire screen, or have them consume all screens on a multi-monitor system. Unfortunately, there is no native way to use only a subset of screens in a multi-monitor setup.
  • Nested virtualization: Need to test detailed environments on Client Hyper-V? No problem! As long as you’ve got sufficient hardware, you can run Hyper-V and Client Hyper-V within Hyper-V. The software does not impose any limitations on depth.
  • Containers. Hyper-V Containers are also available with Client Hyper-V.
  • Network Address Translation in the virtual switch. One place that Microsoft’s desktop hypervisor has consistently lagged behind the competition is its guest networking capabilities. One thing that it has sorely lacked is the ability to perform NAT operations for guests. That meant that you had to have an available IP address on the existing network for each Client Hyper-V guest. Client Hyper-V in Windows 10 will provide network address translation (NAT) services for its guests. This especially comes in handy when you’ve got a wireless adapter that just won’t work with the virtual switch.

What Features does Client Hyper-V Lack in Comparison to Hyper-V?

Most of the features that are “missing” in Client Hyper-V are not especially useful in a desktop-oriented hypervisor environment anyway.

  • Live Migration and Shared Nothing Live Migration: Windows 10 can’t be clustered, so it’s only natural that Live Migration wouldn’t be supported. Shared Nothing Live Migration would have its uses, but it’s not available.
  • Hyper-V Replica: Windows 10 can’t participate as a member in Hyper-V Replica. This particular feature is intended for server-side disaster recovery, so it makes sense that it’s not available in Client Hyper-V.
  • Advanced networking functionality: The only advanced networking available for Client Hyper-V guests is NAT. There is no teaming in the host, not the standard LBFO configuration or switch-embedded teaming (SET).
  • Advanced hardware functionality: virtual fiber channel and some SR-IOV features are not available. The hardware that these features apply to are almost never found in desktop-grade equipment.

Licensing and Client Hyper-V

We’ve produced extensive work around licensing and Hyper-V with articles, eBooks, and webinars. None of them have meaningfully touched on Client Hyper-V. Simply put, a Windows 10 license provides for exactly one instance, period. It does not contain any guest instance rights whatsoever. If you want to run a guest instance of Windows 10, then you must purchase another license to cover that instance. If you wish to run any Windows Server guests on Windows 10, you must license the hardware to cover those instances in accordance with the new per-core rules. Linux distributions will follow their distributors’ rules.

Uses for Client Hyper-V

The benefits of server virtualization are quite clear. They generally center around the fact that server hardware is typically underutilized. That’s usually not the case for client hardware. Desktop and laptop computers don’t usually have as many resources as server computers before you consider cutting them up. CPU is usually the only resource with significant capacity to spare, and even that doesn’t have much availability for some users. So, why would you want to split up limited resources on your desktop system? Here are a few reasons:

  • Software development: Software developers have many reasons to use virtualization.
    • Sandbox environment: If you’re writing systems-level programs, it’s usually not a good idea to allow a bug to cripple the computer that you’re developing on. Checkpoints and kernel isolation alleviate this concern. I particularly like using virtual machines for developing Windows installer packages. Recent versions of Visual Studio rely on Client Hyper-V for testing mobile device applications.
    • Multi-OS targeting: Whatever version of Windows you’re running, almost no developers can guarantee that their users will have the same. Having virtual machines on your desktop allow you to quickly verify that your application runs the same on different operating systems and different bitnesses (32- vs. 64-bit).
  • Systems administration: Systems administrators have many uses for virtualization on the desktop, even though many suffer in silence without realizing that there are solutions to many of their daily headaches.
    • Proper security levels. You know that you are supposed to run in a lowered security environment so that your administrative account isn’t signed in all of the time. You also know that it’s much easier to say than it is to do, especially since even some of Microsoft’s tools don’t work appropriately with Run As. Using virtualization on your desktop allows you to be signed in with multiple accounts simultaneously without the headaches of Run As.
    • User access testing. Another oft-overlooked usage is testing privilege levels for non-administrative accounts. For instance, you can create a test account with the same membership as one of your domain users to test that account’s ability to connect to certain resources. Run As can only take you so far. Logging into a virtual instance with alternative credentials without interrupting anything else that you’re doing is an invaluable capability.
    • Application testing. Software developers may test their software to some degree, but you need to know how it’s going to interact in your environment before pushing it out to your users.
  • Security operations: A virtual machine provides a great many opportunities for information security workers:
    • Sandbox environment: If you’re not certain if something is malicious software, build an environment that it’s free to destroy. Virtual machines present a wonderful walled garden. You can place suspect material inside a VHDX, mark it read-only, then attach it to your checkpointed test virtual machine. If it turns out to be malicious, you can revert the checkpoint or just delete the virtual machine outright.
    • Penetration testing: Build a duplicate of your production environment inside Client Hyper-V instances and hack away. Obviously, there are cons as well as pros to testing against a duplicate of your production environment instead of the actual environment, but this is a good place to start.
    • Forensics labs: Most computer forensic tasks need to be performed on the impacted system(s), but sometimes you need a place to tear into a chunk of code or a data file. Virtual machines provide the perfect environment.
  • Down-level environments: Windows 7 Pro and Enterprise shipped with “Windows XP Mode”, a pre-built Windows XP environment that ran under the built-in Virtual PC type 2 hypervisor. We lost that free virtualized instance along with Virtual PC in Windows 8, but Client Hyper-V still provides the base capability to run down-level operating systems. Unfortunately, Windows XP isn’t on the supported list for Client Hyper-V in Windows 10, but it does work (slowly). Between the defunct Windows XP and the current Windows 10 are four versions of Microsoft’s desktop operating system. There are any number of reasons that you might need one of those environments, at least on a part-time or temporary basis. Client Hyper-V might be exactly what you need.
  • Demonstrations: If you need to demonstrate software or software environments and your simple laptop instance isn’t adequate, you can build very complex structures within Client Hyper-V for use on the road.

Client Hyper-V Requirements

With Windows 10, Client Hyper-V and the server-based Hyper-V have the same hardware requirements. Client Hyper-V is not available in every Windows 10 SKU.

  • Windows 10 Professional, Enterprise, or Education editions. Windows 10 Home edition does not contain Hyper-V, nor do any of the various mobile SKUs.
  • Hardware-assisted virtualization. Intel calls it “VT-x”, AMD calls it “AMD-V”. Most BIOSs usually just have a simple option to enable virtualization features. This technology has been commonplace for long enough that most functional systems will support it.
  • Data execution prevention. An old malware technique involves placing malicious code into a data segment and then directing the CPU to execute it. Data execution prevention forces the system to rigidly respect data segments as not being executable. Intel calls theirs “XD” and AMD calls theirs “NX”. Microsoft unifies them as “DEP”. BIOSs will have various labels that are generally easy to identify. This technology also enough years to be ubiquitous. It’s also typically enabled by default, so you can almost always simply expect it to be present.
  • 4GB of memory. I’m not certain if there is a hard check in place for this condition, but your experience would likely be fairly miserable if you’ve got less.
  • VM Monitor Mode extensions. Intel names theirs “VT-c”. I don’t believe that AMD has any particular name for it. This is a new requirement over Client Hyper-V in Windows 8.x. Even though the name is somewhat foreign to many people, you usually won’t have difficulty providing it. It’s not quite as common as DEP and hardware-assisted virtualization, though. If Client Hyper-V won’t run on your system, this might be why.
  • Second-level Address Translation. Second-level Address Translation (SLAT) has been commonplace on CPUs for several generations. It has always been a requirement for Client Hyper-V. It is an always-on native feature of CPUs and there is no activity to enable or disable it. Check your CPU’s specification sheet to determine if it has SLAT support.
  • (For nested virtualization) Intel VT-x and EPT technology. I don’t know the technical (or perhaps political) details, but AMD users are not welcome in Hyper-V’s nested virtualization world. You need an Intel chip with these technologies available and enabled.

You can quickly and easily verify if you can run Hyper-V on your current system by opening an elevated command or PowerShell prompt and running systeminfo . Look toward the end of the output for the following section:

System Info Hyper-V Check

System Info Hyper-V Check

 

Enabling Client Hyper-V

Client Hyper-V ships as a Windows 10 component, so you don’t “install” it, per se. You enable it.

  1. Right-click on the Start button (or press Win+[X]) and select Programs and Features.
    WinX Menu

    WinX Menu

     

  2. In the Programs and Features window, click Turn Windows features on or off. If UAC is on, you’ll need to confirm switching to administrative mode.
    Programs and Features

    Programs and Features

     

  3. Choose the Hyper-V options that best suit your intent. The only required item is Hyper-V Hypervisor but it will be difficult to do anything with if you don’t enable the other components as well.  This article isn’t going to discuss Containers, but those are enabled here as well, as shown in the screenshot.
    Client Hyper-V Features

    Client Hyper-V Features

     

  4. After clicking OK, you’ll need to restart the computer.

Fewer steps are required to enable Client Hyper-V in PowerShell. In an elevated prompt:

If you’re looking to install a subset of the components from within PowerShell, our earlier article has greater detail.

Using Client Hyper-V

I want to reiterate that, as a type 1 hypervisor, Client Hyper-V is always running. You do not need to start the hypervisor and there is no service that you can go look at or start or stop. There is the Hyper-V Virtual Machine Management service (VMMS.exe), but, as its name explicitly states, it is a management service. Without it, you as the administrator cannot interact with Client Hyper-V, but it is still there and doing its job.

Management Tools

There are three built-in tools that you’ll use to interact with Client Hyper-V:

  • PowerShell. PowerShell is the most thorough way to manage with Hyper-V. You can start it within an elevated standard command prompt by typing PowerShell and pressing [Enter]. I tend to dig it out of the Start menu and pin it to the taskbar.
  • Hyper-V Manager. Hyper-V Manager is not as robust as PowerShell for management, but it is adequate. It is also helpful for connecting to virtual machines’ consoles. Hyper-V Manager can be found in Administrative Tools. I tend to pin this to the Start menu. You must Run As Administrator if you are logged in with a non-administrative account.
  • Virtual Machine Connection. This tool can be invoked within Hyper-V Manager by right-clicking on a virtual machine and clicking Connect. You can also enter vmconnect into any elevated prompt (including the Cortana local search). You will need to Run As Administrator. Once it opens, you can pick the virtual machine that you want to connect to from the drop-down.

It’s worth reiterating that you must always interact with Hyper-V using elevated prompts or graphical applications opened with Run As Administrator. VMConnect is kind enough to tell you when you don’t have sufficient permissions, but most other tools will be silent. For instance, running Get-VM as a non-administrator will simply return nothing, even when virtual machines are present and operational. Hyper-V Manager’s virtual machine list will also be empty.

Configuring Client Hyper-V

I’m not going to take you through every option available for Client Hyper-V, but I’m going to touch on the biggest points. Client Hyper-V works perfectly well immediately after you enable it and reboot, so it’s really just a matter of putting a few final touches on it.

To get started, open up Hyper-V Manager. In Windows versions past, you could simply open the Start menu and start typing “Hyper-V Manager” and after a few keystrokes, the built-in search tool would find it. This still works for most people, but many have encountered a bug where Cortana struggles to find things on the local computer. That went away for me after a few updates but the suggestions that I found to fix it directly did not work for me. If you find the “Windows Administrative Tools” group in the Start menu, Hyper-V Manager is there. I suggest pinning it to the Start menu or something similar so that you can easily reach it later.

Once you have Hyper-V Manager open, it should already have your local computer selected. Right-click on it and click Hyper-V Settings. If that option isn’t available, you didn’t Run as administrator.

A screenshot of the window that you’ll see is below. I’ve changed it to the Physical GPU tab so that you can see that RemoteFX is functioning and has automatically selected the video adapter. Sift through the other tabs and check that items are set as you expect. Feel free to change things as suit your needs. I would recommend keeping Enhanced Session Mode enabled everywhere you find it, or you’ll lose some host/guest interaction capabilities with your virtual machines. If you’re not certain about a setting, the best thing to do is leave it alone.

Basic Configuration

Basic Configuration

 

Once you’re finished there, right-click on the local computer again and click Virtual Switch Manager. Make certain that, on the right side, the selected type is External and click Create Virtual Switch.

Starting Virtual Switch Manager

Starting Virtual Switch Manager

 

Set the following options on the new virtual switch page:

  • Name the virtual switch. There is no need to get fancy with this. Use something that you can remember and that you can type. Future you will thank you.
  • Next to the External network dot, choose the physical network adapter that will host the virtual switch. You may need to look in your network adapter list if it’s not obvious which is which.
  • Unless you have multiple virtual network adapters, leave Allow management operating system to share this network adapter. If you don’t, the physical adapter that you choose will be able to connect virtual machines to the physical network, but you’ll have to manually create a virtual NIC for the management operating system (that’s the Windows 10 installation that’s running Client Hyper-V) to continue using the physical network (or come back in here and check the box).
  • If your management operating system currently participates in a VLAN, check the Enable virtual LAN identification for the management operating system and enter the necessary VLAN ID in the text box. If you’re at home using regular home networking equipment, you’ll definitely want to skip this box. If you’re connected to commercial-grade equipment at work and don’t already know what to do, it’s highly likely that you will skip this configuration. Otherwise, talk to your network administrator.
Virtual Switch Manager

Virtual Switch Manager

 

When you’re done with setting up the virtual switch and you OK out, you might lose connectivity for a few moments while the networking settles down. It needs to recreate your networking stack on a new virtual adapter, so expect that to take a bit of time.

If you connected to a wireless network adapter, you might face some difficulties. You wouldn’t be the first. I do not personally have much expertise in addressing these problems but your odds of finding suitable resolution are not great. Usually, it either works in the beginning or it never works at all. You can try updating drivers. If you just can’t get it to work, never fear! You can follow the steps in the next section to create a NAT network so that you don’t need a virtual switch on top of the physical adapter.

Configuring NAT Networking in Client Hyper-V

This process has changed several times since the feature was introduced in a technical preview of Client Hyper-V and a lot of the currently available instructions are wrong. Even Get-Help for New-VMSwitch shows options that don’t work. The following instructions were tested and known good for Client Hyper-V on Windows 10 build 14393.447 (run “winver” from the Start menu).

As with many things in Windows, there is more than one way to make this all happen. There is only a single step that absolutely requires PowerShell, which means that I’m going to counsel you to do the whole thing in PowerShell. You can do all the other steps in the GUI if you prefer. So, I’ll start with a basic outline of the steps, then I’ll show you the PowerShell that can make it happen:

  1. Determine what network range you want your NAT network to be. You only get a single NAT network on a Client Hyper-V system.
  2. Create an internal virtual switch.
  3. On the management operating system’s adapter for the internal virtual switch from step 2, assign an IP that will function as the router IP on that network that you thought up in step 1.
  4. Create the NAT network (PowerShell only).
  5. Attach virtual machine(s) to the virtual switch that you created in step 2 on the network that you created in step 1 using the IP that you assigned in step 3 as the router.
  6. Assign IPs from within the guest operating systems.

Be mindful of step 6. Client Hyper-V does not contain a DHCP server and will not distribute addresses for that NAT network. In case you were about to ask, no, Client Hyper-V does not support DHCP relay, either. You must either create a virtual machine running DHCP in that network or you must manually assign IPs. I’d go with the latter.

Here are steps 2-4 in PowerShell for the network 192.168.100.0/24 (192.168.100.1 through 192.168.100.254):

The first line creates an internal virtual switch named “vSwitchNAT” (could be done in Hyper-V Manager, as you saw above). An internal switch allows the host operating system and guest operating systems to use the same virtual switch, which, by definition, means that a virtual adapter will be automatically created for the management operating system. When such a virtual adapter is automatically created, its name is always in the format of vEthernet (name of the virtual switch), so I know that this one will be named “vEthernet (vSwitchNAT)”. If you name your virtual switch differently, use that name on your second line. I have also decided to pick the first valid IP in the network that I created, hence the 192.168.100.1 (this could be done in network connections). Note that I do not give it any routing information, such as a default gateway. The third line creates the NAT network. It will see the adapter with IP 192.168.100.1 and automatically treat it is as the router for that network.

Now, I just need to connect virtual machines to it. On the properties for a virtual machine, I do exactly that:

Select NAT Switch

Select NAT Switch

 

I finish up by accessing the guest’s networking and giving it an IP on that network and using the host management adapter as the default gateway:

NAT Client IPv4

NAT Client IPv4

 

NAT in Windows 10 has more capability than what I’ve shown you, but this should be enough for most. Start on the NAT PowerShell page for more information.

Continuing On…

There are a great many other things that I could show you, much more than would fit in a simple blog post. If this is your first time using Client Hyper-V, or any Hyper-V, spend some time kicking the tires. Begin by right-clicking your host in Hyper-V Manager and clicking New and Virtual Machine. The wizard should be easy enough to follow. Once your new VM is created, right-click on it and click Connect. That’s VMConnect. You’ll find the start and stop controls. You’re now on your way to being a Client Hyper-V guru!

How to Work with Hyper-V Virtual Network Adapters

How to Work with Hyper-V Virtual Network Adapters

Hyper-V’s Virtual network adapters are the windows that your virtual machines — and sometimes your management operating system — use to communicate with the rest of the world. You can perform basic adapter manipulation for virtual machines using the GUI. Advanced functionality, and anything to do with virtual adapters in the management operating system, require PowerShell.

Virtual Adapters Do Not Change Ethernet and TCP/IP Behavior

Before I get into the how-to, I want to take a very brief detour to address probably 80% or more of the questions that I see involving virtual network adapters. Hyper-V’s virtual network adapters exhibit the same logical behavior as a physical network adapter. Guest operating systems treat them no differently than physical adapters. If you’re about to post a comment or question claiming that Hyper-V is stopping your PING or blocking your web traffic, don’t. You need to understand the Hyper-V virtual switch. You need to understand Ethernet and TCP/IP.

Remember that guest operating systems come with firewalls. Remember that virtual network adapters can be assigned, or not be assigned, to VLANs. The management operating system’s firewall does not impact anything happening on any physical adapter hosting a Hyper-V virtual switch nor does it impact any virtual network adapter except those assigned to the management operating system. If that doesn’t make sense to you, then you do not understand the Hyper-V virtual switch.

Two Types of Hyper-V Virtual Network Adapters

Hyper-V provides two types of virtual network adapters.

  • Legacy Network Adapter: The legacy network adapter is only available for generation 1 virtual machines. It is an emulated device, meaning that Hyper-V creates a complete digital reconstruction of a common, basic physical network adapter. This adapter type exists for those situations in which there is no way for a particular guest to load the standard Hyper-V network adapter. In most cases, this is for PXE booting Generation 1 virtual machines. Any other cases would involve unsupported operating systems that have no driver for the standard virtual adapter. This adapter is locked at about 100Mbps speed and requires a comparatively high amount of CPU processing, so avoid using it in situations that do not strictly require it.
  • [Synthetic] Network Adapter: Usually only named as a “Network Adapter”, Hyper-V’s synthetic network adapter is a connection between Hyper-V’s VMBus or an IOV Virtual Function and the virtual machine or management operating system. It is substantially faster than the legacy network adapter.

Use PowerShell to Create a Virtual Network Adapter for a Guest Operating System

Use Add-VMNetworkAdapter to create a virtual network adapter. I do not know why this cmdlet does not use the New verb. In 2012 R2 and earlier, the virtual machine must be Off to add a new virtual adapter.

The above will create a virtual network adapter named “Virtual Adapter”, attach it to the virtual machine named “svtest”, and leave it disconnected.

During adapter creation, you have the option to name the adapter, set a static MAC address, specify that it is the legacy type, connect it to a virtual switch, and assign it to a resource pool. The following example shows some of these options:

Even though I gave the adapter a name that includes a VLAN, it’s just a name. You cannot use Add-VMNetworkAdapter to specify a VLAN. That’s a different cmdlet, which I will show later in this post.

Tip: When adding a virtual adapter to a system that already has a virtual adapter, override the Name. This makes it much easier to work with the adapter later.

You can add a virtual adapter to many virtual machines at once:

Use PowerShell to Display Virtual Machines’ Virtual Adapters

Use Get-VMNetworkAdapter to view virtual adapters. This cmdlet always has some required parameters, so it cannot be used alone.

To retrieve the adapter(s) for a specific virtual machine:

When run against the virtual machine that I used the previous examples on, this is the output:

If the virtual machine were on, the MacAddress fields would be populated. If the virtual machine were on and the guest KVP exchange service is running/functional, the IPAddresses would be populated. What you don’t see is that the last adapter is a legacy adapter. You can use -IsLegacy to filter for synthetic adapters (with $false) or legacy adapters (with $true):

You can also use formatting to see all/other properties. Our introductory article on PowerShell includes a section on formatting.

View all virtual adapters on all virtual machines:

You can also use a partial match in the VMName field, ex “svweb*”.

View all virtual adapters on the host, including those for the management operating system:

Everything that we’ve shown you to this point displays the virtual network adapter(s) on the screen. The output of Get-VMNetworkAdapter is a true object. It can be passed via the pipeline to other cmdlets, such as Remove-VMNetworkAdapter. Our introductory PowerShell article discusses the pipeline.

Use PowerShell to Remove a Virtual Machine’s Virtual Network Adapter

Not surprisingly, Remove-VMNetworkAdapter is the cmdlet to remove a virtual adapter. Be aware that this permanently deletes the virtual adapter! Even if you later recreate it with the same settings, it will have a different hardware signature than the one that you removed. If you just want to unplug an adapter from a virtual switch, see the section on Disconnect-VMNetworkAdapter below. The virtual machine must be Off to remove a virtual network adapter.

Remove an adapter from a virtual machine by name:

We have a little problem on the virtual machine named “svtest” from our previous operations: two virtual network adapters with the same name. The best way to deal with this problem is to use Get-VMNetworkAdapter to find something different about the adapters. From there, use the pipeline to remove the unwanted adapter. I have two options in this case. First, the unwanted adapter is not connected to a virtual switch. Second, the unwanted adapter doesn’t have a MAC address. If neither of those clues are helpful, I could turn the virtual machine on and wait for the IPAddresses field to populate. I could then determine the MAC address of the adapter to remove and use that.

To remove all virtual adapters from a virtual machine that aren’t connected to a switch:

The “?” is an alias for Where-Object. That was also explained in our introductory article, but the simple explanation is that we are retrieving all virtual adapters on that particular virtual machine and then filtering to only the adapters that don’t have a virtual switch.

Tip: The Remove-VMNetworkAdapter cmdlet has a -SwitchName parameter that allows you to easily remove adapters connected to a particular virtual switch. That parameter cannot be null or empty, so the above is the only way to remove disconnected virtual adapters.

To remove a virtual adapter from a virtual machine by MAC address:

Remove all virtual network adapters from a virtual machine:

Use PowerShell to (Dis)Connect a Virtual Network Adapter To/From a Virtual Switch

The Connect-VMNetworkAdapter and Disconnect-VMNetworkAdapter cmdlets can be used to connect and disconnect virtual machines’ virtual network adapters to/from virtual switches. The virtual machine can be On or Off when using these cmdlets.

The most common way to use both of these cmdlets is by virtual machine name, since most virtual machines use only a single adapter. To connect all of the adapters on a specific virtual machine to a specific virtual switch:

To disconnect them again:

You can use the pipeline for more granular control:

Use PowerShell to Add a Virtual Network Adapter to the Management Operating System

Use Add-VMNetworkAdapter to create a virtual network adapter for the management operating system, much like you do for virtual machines.

The above will add a virtual adapter to the management operating system on the first virtual switch that it finds. The newly created adapter will have the same name as the virtual switch when using the *-VMNetworkAdapter cmdlets. In all other locations and tools, it will be called vEthernet (<name_of_the_virtual_switch>).

To create a virtual network adapter in the management operating system with a more descriptive name:

Tip: Virtual adapters in the management operating system must always be connected to a virtual switch, and they must remain connected to the same virtual switch from cradle to grave. There is no way to disconnect them or reconnect them to a different virtual switch.

Use PowerShell to Remove a Virtual Network Adapter from the Management Operating System

Remove-VMNetworkAdapter is also used to remove a virtual adapter from the management operating system. Just as it does with a virtual machine, this cmdlet permanently deletes the virtual adapter

Use PowerShell to Modify a Virtual Adapter

Set-VMNetworkAdapter can control the following settings for virtual adapters connected to either a virtual machine or the management operating system:

  • DHCP Guard: When set to on, this virtual network adapter will never receive any Discover or Request frames in a DHCP DORA conversation. That way, if the guest operating system is running a DHCP server, it will never issue IP addresses. This is mostly useful in hosting environments, but can be put into action anywhere that the Hyper-V administrator doesn’t really trust the administrator of the guest operating system.
  • Dynamic/Static MAC Address: Instructs the network adapter to use a MAC address generated by its host or one specified by you. Windows guests should be fine with a dynamic MAC address, but Linux guests will require a static MAC address if they will ever be Live Migrated.
  • Maximum IPSec Offload Associations: If you’re using IPSec and you want to prevent a virtual adapter from offloading too many IPSec associations, this cmdlet has you covered.
  • Enable or disable 802.1p tagging: This feature is mostly useful in hosted or other cases when you may not be able to trust the administrator of the guest operating system. In order to have any effect, your physical network must be processing 802.1p tags. If 802.1p tagging is enabled, then the guest operating system can transmit tags with an 802.1p priority set. If tagging is disabled, Hyper-V will reset the 802.1p section of all Ethernet frames leaving this adapter to 0.
  • SR-IOV settings. If your virtual switch and hardware is IOV-enabled, use this cmdlet to control the moderation method and weight of an individual virtual network adapter. If you want to prevent a virtual adapter from ever using a Virtual Function, you can set its -IovWeight parameter to 0.
  • MAC addressing spoofing: If disabled, then the guest operating system administrator will not be able to use in-guest tools to override the MAC address of the adapter. You’ll want this off if the guest operating system is employing network load balancing.
  • Hyper-V QoS Settings: this cmdlet controls all of the Hyper-V QoS settings for virtual adapters.
  • Cluster monitoring: By default, the cluster will Live Migrate the virtual machine if it detects that one of its adapters has lost network connectivity. You can disable this protection with this cmdlet.
  • Port mirroring: You can set Hyper-V to mirror the traffic of one virtual network adapter to another. I’ve heard complaints that this feature does not actually work, but I’ve never tested it myself.
  • Router guard: When enabled, the virtual adapter will not be able to send out Router Advertisement or Redirection packets. This will generally prevent the guest operating system from establishing itself as a rogue router. Packets directed specifically to its MAC address for routing will still pass, however.
  • Storm protection: limits the per-second outbound flow rate of an adapter.
  • VMQ weighting: You can establish the hierarchy of this virtual adapter when registering for a queue, or you can set VmqWeight to 0 to prevent it from receiving a queue at all.
  • Teaming: If you’d like to team virtual network adapters within the guest, you’ll need to enable the feature at the virtual adapter level first. This cmdlet can do that.

The above list isn’t quite exhaustive, but hits the most common and some of the less common items. I linked the help page for the cmdlet at the very top of this section so that you can discover many of these parameters easily. I’m not going to show you everything possible. I’ll demonstrate a few items.

Setting Hyper-V Virtual Adapter Quality of Service

Both the GUI and PowerShell are a bit clumsy for setting network quality of service, but overall, PowerShell is better. It’s also the only way to set QoS for virtual adapters in the management operating system.

If you’ve gotten this far, then you should already know how to select a virtual network adapter by -VMName or -ManagementOs and by -Name. You should also know how to use pipelining to select a virtual adapter by other criteria, such as its MAC address. I will only be showing such things incidentally in this section.

First, you need to know what QoS mode your virtual switch is in:

If it is Weight, then you can set the -MinimumBandwidthWeight parameter on its virtual adapters. If it is Absolute, then you can set the -MinimumBandwidthAbsolute parameter instead.

The weight mode is a percentage. To set a virtual adapter so that it can reserve up to 20% of available bandwidth:

If you use Absolute, specify -MinimumBandwidthAbsolute as a numeric value with the minimum number of bits per second. According to the documentation, the number that you supply will be rounded to the nearest multiple of 8 and should be greater than 100Mbps.

For either mode, the upper QoS limit is specified in bits. You cannot set a percentage limit. I would recommend using the PowerShell multipliers. To restrict all adapters on a virtual machine to 250Mbps (separately):

Statically Assigning an Automatically Generated MAC Address to a Virtual Network Adapter

This is a little trick I use with my Linux virtual machines. I first turn them on so that they are automatically assigned a MAC address by the host. Then, I shut them off and run the following:

Whatever MAC was dynamically assigned is now the permanently assigned static MAC address.

Use PowerShell to Set a Virtual Network Adapter’s VLAN

Use Set-VMNetworkAdapterVlan to control the VLAN for a virtual network adapter. I’m again going to assume that you read the above and know how to select a virtual network adapter with -ManagementOs and -Name or by -VMName and, if necessary, pipelining and ?/where.

Assign a virtual network adapter to a specific VLAN:

Remove a virtual adapter from all VLANs:

Warning: Never assign a VLAN ID of 0. If the cmdlet were better designed, it would generate an error when you try, because the only valid VLAN IDs are from 1-4096. VLAN ID 0 is undefined — an all-zero VLAN tag is only used across trunk ports and is treated as the native or default VLAN on devices that support it. Hyper-V does not know how to handle a virtual network adapter with a 0 VLAN ID and traffic will not flow.

I’m not going to demonstrate the Promiscuous, Isolated, and Community mode settings, mostly because I think that 99% of the people that try to use them don’t understand what they do and don’t actually have a use case for their true purposes. A Hyper-V network adapter in promiscuous mode does not capture frames headed to other network adapters. These modes are used in extended VLANs only. If you understand what those are and have a need for them, run Get-Help Set-VMNetworkAdapterVlan -Examples to see how to use the related parameters.

Use PowerShell to Rename a Virtual Network Adapter

Only PowerShell can be used to rename a virtual network adapter, but the selected name will show up in most GUI tools that can see the adapter. As with the previous two sections, I’m not going to reiterate how to select the adapter that you want to change.

Use Hyper-V Manager/Failover Cluster Manager to Add a Virtual Network Adapter

These GUI tools can only be used to add adapters to a virtual machine. You must use PowerShell to add a virtual network adapter to the management operating system. The guest must be Off to add an adapter.

  1. In either tool, right-click a virtual machine and click Settings. You must use Failover Cluster Manager for clustered virtual machines.
  2. The first screen that opens should always be the Add Hardware tab. Select that tab on the left if necessary.
  3. Highlight Network Adapter or Legacy Network Adapter (generation 1 VMs only). Click Add.
  4. You will be viewing the property page for your new adapter. It will not actually be created until you click OK or Apply. Click Remove or Cancel if you don’t want to add it.
Add Virtual Network Adapter

Add Virtual Network Adapter

 

Use Hyper-V Manager/Failover Cluster Manager to Modify or Remove a Virtual Network Adapter

  1. In either tool, right-click a virtual machine and click Settings. You must use Failover Cluster Manager for clustered virtual machines.
  2. On the left, you’ll see the virtual network adapter(s). By default, they’re all named “Network Adapter” or “Legacy Network Adapter”, although they might have been renamed. Look for the icon.
  3. The primary settings are on the first page that you land on. If you wish to delete the adapter, click Remove. Upon clicking OK or Apply, this removal is permanent! Other settings can be reached by expanding the item by click the small + icon next to the adapter on the left. All screens are shown below.
Main Property Page for A Virtual Network Adapter

Main Property Page for A Virtual Network Adapter

 

Virtual Network Adapter Acceleration Page

Virtual Network Adapter Acceleration Page

 

Virtual Network Adapter Advanced Settings

Virtual Network Adapter Advanced Settings

 

Most of these settings are very well-described in the dialogs. You can also refer to the PowerShell entries above, as these are graphical equivalents of those settings (a handful of items can only be set in PowerShell).

If your virtual switch is in Weight QoS mode, I recommend only using PowerShell to make adjustments. The dialog is worded only for Absolute mode and you will typically be unable to use it to set the minimum. I more strongly recommend avoiding setting QoS on individual VM network adapters at all. It’s rarely necessary.

If you don’t like PowerShell much but need to do bulk settings, you can use the GUI to configure a model adapter and then, with a little tinkering, use PowerShell’s pipeline to massively distribute those settings to other adapters. I’ll leave that for your exploration (there’s really no one-size-fits all method or I’d show it).

How to create a Hyper-V Virtual Switch

How to create a Hyper-V Virtual Switch

 

The first stage of getting your Hyper-V virtual machines onto the network requires a Hyper-V virtual switch. If you don’t have much knowledge of the virtual switch, I strongly recommend that you read through our earlier article that explains it. Newcomers, even those with experience in other hypervisors, often encounter many issues with the virtual switch until they understand how it operates. This article applies to Hyper-V versions 2012 and 2012 R2. Most will be applicable to Windows 8.1 and 10 although Client Hyper-V does not have quite as many switch options.

What is the Hyper-V Virtual Switch?

Hyper-V’s virtual switch is exactly that: a digital construct that provides the same functionality as a physical switch. One difference is that it does not have a fixed number of ports. Those ports are also not numbered. In fact, you, as a Hyper-V operator, really have no visibility into the ports themselves. We only operate on the switch and on the virtual network adapters. Virtual network adapters are used by both the management operating system and by virtual machines. We connect those adapters to the switch and then it is responsible for moving information. For the most thorough explanation, refer to the article linked in the first paragraph.

For this article, there are a few things that you need to know right up-front:

  • The Hyper-V virtual switch can work with 802.1q VLANs. It does this automatically without any special configuration. It does not have a default or “native” VLAN. Unless otherwise specified, packets travel without a VLAN tag. While not technically correct, this is often called “VLAN 0”. You can read our article on VLANs if you do not already have comfortable knowledge of this technology.
  • The network quality-of-service (QoS) mode for the Hyper-V virtual switch can only be set at creation time. The documentation for 2012 and 2012 R2 insists that the default mode is Weight. This is incorrect. The default mode is Absolute.
  • The internal and private virtual switch types do not use a physical network adapter, therefore they can only transfer data between virtual network adapters.
  • The external virtual switch uses a physical network adapter or team of physical network adapters. Once a virtual switch has been assigned to an adapter or team, it completely controls all traffic inbound and outbound. You cannot use it for any other purpose (although you can attach a virtual network adapter within the management operating system to the virtual switch). Do not attempt to manipulate the bindings and protocols on a physical adapter or team that has a virtual switch assigned. Along that path you will find only heartache.
  • It is not recommended to have more than a single external virtual switch per host. It is usually needless overhead. Use convergence to your benefit.
  • Private and internal virtual switches are for isolation, not performance. They cannot be used with clustered virtual machines (VMs attached to private/internal virtual switches will not migrate).
  • The physical adapter or team for a virtual switch must not be configured with a VLAN. Perform all VLAN-related operations on the physical switch and individual virtual network adapters.
  • If you use a physical adapter team, only the teaming mechanism provided natively by Windows/Hyper-V Server 2012 or later is supported. Do not use your adapter’s software.
  • When you create a team of adapters using the native tools, it creates a single logical adapter to represent the team by default. This is what the Hyper-V virtual switch is attached to. The team has the ability to create other logical adapters, but it is not supported to use multiple logical team adapters alongside the Hyper-V virtual switch. It is functional, however. One issue that you might run into is that network QoS behavior is not defined in this configuration.
  • The Hyper-V virtual switch can operate in Single-Root I/O Virtualization (SR-IOV) mode. This technology allows a virtual machine to communicate directly with the network adapter, almost entirely bypassing the Hyper-V virtual switch. This article is not about SR-IOV, so I’ll only give it a brief treatment here with these notes:
    • SR-IOV does improve performance, but the difference is not major and is not even noticeable except under very heavy, and very unusual loads.
    • SR-IOV must be supported by your network adapter(s). Your adapter will limit the number of SR-IOV virtual adapters that you can create. Look for its number of “Virtual Functions” in the manufacturer’s specifications.
    • SR-IOV drivers for your management operating system must exist.
    • SR-IOV must be supported by your host’s motherboard and it must be enabled in BIOS/UEFI.
    • SR-IOV must be supported by the guest operating system. Versions of Windows Server 2012 and later qualify. For some systems, you may also need to install some software from the manufacturer inside the guest.
    • SR-IOV virtual switches only work as expected if they are connected to a single virtual adapter, not a team.
    • A Hyper-V virtual switch can only be enabled for SR-IOV at creation time.
  • My Hyper-V knowledge is focused on the server side, so I know very little about attaching virtual switches to wireless adapters. I know that many of the people that try run into troubles. I can’t help you with those problems.

Creating the Hyper-V Virtual Switch

There are three ways using the freely-available tools to create a Hyper-V virtual switch:

  • PowerShell
  • Hyper-V Manager
  • Add Roles Wizard (during Hyper-V installation)

Purchased and third-party tools, such as System Center Virtual Machine Manager, can also create switches for you.

Creating a Hyper-V Virtual Switch Using PowerShell

PowerShell is the fastest and preferred way to create a Hyper-V virtual switch. It is the only method by which you can set the Quality of Service (QoS) mode. We’ll go over most of the common settings here, but more thorough documentation about the New-VMSwitch cmdlet is available on TechNet. You can also use Get-Help Get-VMSwitch.

We’ll start with a private switch, because that’s the easiest:

An internal switch is created almost the same way:

The outcome is different. The above will create a switch and a virtual network adapter in the management operating system with the same name as the switch. If you used exactly what I typed, you could view that adapter with: Get-VMNetworkAdapter -ManagementOS -VMNetworkAdapterName vsInternal.

Remember that the presence or lack of a virtual adapter for the management operating system is what distinguishes the private from the internal virtual switch. If you remove all of the management OS adapters from an internal switch, it becomes private. If you add an adapter in the management operating system to a private switch, it becomes internal.

Next, we’ll create an external switch using most of the available options. But, there is one little catch. We have to know which physical adapter or adapter team to connect our virtual switch to. The nice thing about the PowerShell cmdlet is that, unlike any of the other methods, we can do this by the adapter’s name. The other tools require that you select from the adapter “Description” field, which is not very descriptive. If you don’t already know the name of the adapter that you wish to use:

That will retrieve a list of all of the network adapters on the system. You can then pick the name of the adapter that you want. If you’d rather, you can use the adapter’s description field, although it is usually truncated on the default view. This might help:

Remember that copy/paste does work in PowerShell. Click to drag a selection box around what you want. You can then use [Enter] to paste. If the automatic copy/paste doesn’t work, right-click on the PowerShell window’s title bar and select Edit -> Mark to begin copy mode.

With the name or description in hand, you can now create an external virtual switch. Let’s create one with SR-IOV left off but with QoS mode set to Weight. This is the most commonly desired configuration. If the adapter that I wanted to use had a named of “NIC 1 Port 2”, this is what the cmdlet would look like:

If I had used $true for AllowManagementOS, a virtual adapter would have been created in the management operating system on the new switch with the same name as the switch. You can use Add-VMNetworkAdapter and Remove-VMNetworkAdapter at any point in the future, so your selection at creation time is not permanent.

Let’s create the same switch with SR-IOV enabled:

For both AllowManagementOS and EnableIov, you can use $true or $false or 0 or 1. For MinimumBandwidthMode, you can press [Tab] to cycle through your options, which are Weight, Absolute, Default, and None.

Remember that MinimumBandwidthMode and EnableIov are permanent! If you do not select the option that you want at creation time, you cannot change it! Your only option is to destroy and recreate the virtual switch.

Creating a Hyper-V Virtual Switch Using Hyper-V Manager

The second best option for creating a Hyper-V virtual switch is using Hyper-V Manager. It does have the ability to enable SR-IOV, but it cannot set the QoS mode.

  1. Begin by opening Hyper-V Manager. On the right, in the Actions pane, click Virtual Switch Manager.
    Open Virtual Switch Manager

    Open Virtual Switch Manager

     

  2. The Virtual Switch Manager screen will open. On the left, it should have New virtual network switch highlighted. Click it otherwise to go to the Create virtual switch page as shown. It really doesn’t matter which of the three items that you pick here, as you’ll get another chance to select the type that you want. Click the Create Virtual Switch button.
    New Virtual Switch Page

    New Virtual Switch Page

     

  3. The dialog is shown below. I’ll explain each of the options afterward. Make your selections and click OK to enact them and close the dialog immediately or click Apply to enact your changes but leave the dialog open. You can continue creating new virtual switches until you have all that you need and then click OK.
    New Virtual Switch

    New Virtual Switch

     

These are the options from the above screen:

  • Name: This is the name of the virtual switch that will be created. Remember that for Live Migrations, it needs to match on all nodes.
  • External network: Selecting this option will create an external virtual switch (regardless of what option that you selected on the previous screen). If you select this option, you’ll also need to pick an adapter by its Description. You can match these up by their property sheets in Network Connections.
  • Allow management network to share this network adapter: The wording of this label is horrible. There is no “sharing”. If checked, a virtual network adapter will be created for the management operating system on the new virtual switch. It will have the same name as the virtual switch.
  • Enable single-root I/O virtualization (SR-IOV): If you check this, the virtual switch will be enabled for SR-IOV. You must still meet all the requirements as listed at the top of this article. Remember that this setting is permanent!
  • Internal network/private network. Choosing either of these disables all the settings underneath External network and makes the switch internal or private, as desired.
  • Enable virtual LAN identification for management operating system. This is another badly worded label. If you are creating either an external virtual switch with the Allow… box checked or an internal switch, this checkbox and its text box will be enabled. If you select it, you’ll need to enter a number in the text box. That will be the VLAN assignment for the virtual network adapter created for the management operating system. This setting does not assign any VLAN information to the virtual switch itself because that cannot be done in Hyper-V.
  • Remove. If you made a mistake and don’t want the virtual switch, you can click this button. It will also remove an existing virtual switch.

Create a Virtual Switch with the Roles Wizard During Hyper-V Installation

My least favorite way of creating a virtual switch is using the roles wizard. It doesn’t give you any of the options that you saw in the previous methods.

This post is only about creating the virtual switch, not installing Hyper-V. If you’re reading this section, I assume that you are in the process of installing Hyper-V and are wondering what to select on this screen. Therefore, I’m not going to show the entire wizard. The screen in question appears below:

Virtual Switch in Roles Wizard

Virtual Switch in Roles Wizard

 

My recommendation for the above is that you check nothing. Continue through to the end, allow it to perform all of its installation and reboots that it likes, then use one of the two methods shown above to create your virtual switch. The reason is that you cannot select whether or not to create a virtual adapter for the management operating system, which QoS mode to use, or to enable SR-IOV.

If you’re running a fairly small system, maybe neither of those matter to you. In all honesty, even a lot of medium-sized installations don’t really need to worry about them. But, I prefer setting things just the way that I like them and never worrying about it. If you really don’t care, all that you need to do is select one of the network adapters shown in the list. A virtual switch will be created along with a virtual network adapter for the management operating system. If you select multiple adapters, one switch will be created for each.

Post-Creation Notes

A newly created Hyper-V virtual switch is ready to use immediately — no reboots or fancy configurations are required. It will show up right away as an option to attach virtual network adapters to.

A few things:

  • If you made a mistake a long time ago and don’t have the switch in the mode that you like, don’t panic! Before you do anything, honestly answer this question: Do you have a problem? By problem, I don’t just mean that it’s not in the configuration that you like. I seriously mean, is there a problem that can only be fixed by switching one of those modes? If the answer is “no”, then walk away and leave it be. Surely you have bigger things to worry about than a misconfiguration that’s not hurting anything.
  • To create additional virtual network adapters for the management operating system, you must use Add-VMNetworkAdapter.
  • If traffic isn’t working across your new switch, either the VLANs don’t match up between physical and virtual or something is wrong with TCP/IP. The virtual switch is such a simple construct that there really isn’t anything else that could be wrong (virtual switches on WiFi adapters are another matter and beyond this post).
  • Just to reiterate, do not tinker with the bindings or protocols for the physical adapter or team adapter that hosts an external switch. No matter what is wrong, this sort of thing can only make it all worse. If you’re certain that your virtual switch is really broken, remove it and create a new one. If you can’t remove it for some reason, use Hyper-V Manager or Set-VMSwitch to convert it to an Internal or Private switch, then try to remove it.

 

 

Network Ports Related to Hyper-V

Network Ports Related to Hyper-V

 

I firmly believe that Hyper-V is best implemented using Hyper-V Server and remote management techniques. Set it up once and never connect to its console again. With a bit of creativity, you can even deploy vendor-supplied firmware updates without accessing a local session. My approach does not enjoy community consensus; in fact, I’m unaware of any general agreement on the matter at all. One thing I do know for certain is that humans follow the path of least resistance. If option A is more difficult than option B, almost everyone will follow option B. Even people that take the hard road a few times at first will eventually fall back to the easy route, especially in times of distress.

With all of that said, I also firmly believe that digital security needs to be taken seriously. You may be in a low-security environment that doesn’t handle any sensitive information, but there is still a basic level of expected due diligence. Attackers are sometimes out to steal storage space and network bandwidth, not information. You have a responsibility to at least attempt to prevent that from happening. Even if you don’t feel like you owe to your current employer for whatever reason, you might want to work somewhere else someday. No prospective employer will be impressed if you have developed poor security habits.  Good security practice involves firewalls. Yes, they’re annoying when they inhibit legitimate traffic, but they are a simple and effective way to stop the most common assaults.

This article has two purposes. The first is to succinctly lay out the TCP/IP network ports information for Hyper-V management and activities. This allows you to configure firewalls as necessary. The second is to help you through some configuration dos and don’ts. This article might have information that helps you connect to workgroup-joined Hyper-V host, but it was not written with that usage in mind. I have not heard any compelling reason for that configuration to exist, therefore, I will not waste any further energy enabling it.

Inbound Hyper-V-Related TCP/IP Ports

The rules table below is used on 2012 R2 and should also apply to 2012. Every firewall configuration is a bit different. The following diagram gives a generalized idea of where you’ll be working:

Location of Firewall Rules

Location of Firewall Rules

Hyper-V Host Inbound Rules
Port Target Source Purpose
All dynamic ports (49152-65535) Management IP; CNO Management servers and stations; RDS broker Server Manager and other tools that use Remote Procedure Call
80 Management IP Other Hyper-V hosts that can replicate to this host Hyper-V Replica (only if using insecure traffic)
135 Management IP Management servers and stations; RDS broker RPC Endpoint Mapper (sometimes for WMI as well)
443 Management IP Other Hyper-V hosts that can replicate to this host; VMM servers Hyper-V Replica (only if using secure traffic) and System Center VMM
445 Management IP and Cluster IPs; Live Migration IPs if using SMB mode Management servers and stations that would copy files to this host; members of the same cluster; Live Migration sources if using SMB mode; RDS broker Inbound file copy; cluster communications; Cluster Shared Volumes redirected access; Live Migration if using SMB mode
2179 Management IP; CNO Management servers and stations; RDS broker Communication to Virtual Machine Management Service
TCP & UDP 3389 Management IP Management stations Console access
5985 Management IP Management servers and stations; RDS broker WSMan and WMI; notably used by PowerShell Remoting
5986 Management IP Management servers and stations; SCVMM Secure WSMan and WMI
6600 Live Migration IPs Other Hyper-V hosts that can Live Migrate to this host Live Migration when using standard TCP or compressed TCP modes

The above table should be mostly self-explanatory. There are a handful of notes:

  • You probably don’t need to open all dynamic ports. I’ve only seen the first five or six ever actually being used. The problem is, if Microsoft has documented the true range of used ports anywhere, I have never found it. I only stumbled on the necessity to open the ports at all via netstat and Wireshark traces from failing connections. PSS didn’t even know about them.
  • For the best outcomes, do not use any firewalls at all on cluster-only networks. The above will work, but (unscientifically), the Wireshark traces I’ve seen on cluster networks suggest that it uses other undocumented methods for communications that are likely more efficient. This would not apply to cluster-and-client networks such as the management network. Keep all of your cluster-only networks in the same layer-2 network with no routers, preferably in a VLAN or otherwise isolated network.
  • “CNO” is cluster name object. Server Manager in particular wants to be able to talk to it. In reality, it maps directly to the management IP of the host that currently maintains the cluster core resources and as long as Server Manager can reach that, everything will be fine even if Server Manager is displeased. If you can ignore Server Manager’s complaints, so can I.
  • “RDS” is “Remote Desktop Services”. I hope the clarification isn’t necessary, but this is for virtual machine RDS and not session-based RDS.
  • Very few things have any need to use 5986 because WSMan traffic is always encrypted. Your host will only be listening on 5986 if you enable secure WSMan with a specially configured WinRM listener.

Outbound Hyper-V-Related TCP/IP Ports

Most institutions won’t block traffic outbound. However, you might need to use it to configure the inbound firewalls on other hosts. It’s also helpful if you have interim hardware firewalls. The rules are presented from the perspective of the following diagram:

Hyper-V-Related Outbound Firewall Rules

Hyper-V-Related Outbound Firewall Rules

Hyper-V Host Outbound Rules
Port Target Source Purpose
All dynamic ports (49152-65535) Management IP of other Hyper-V hosts; RDS broker Management IP Server Manager and other tools that use Remote Procedure Call if you will manage one host from another; RDS broker if using RDS
80 Other Hyper-V hosts that this host will replicate to Management IP Hyper-V Replica (only if using insecure traffic)
135 Management IP Management servers and stations; RDS broker RPC Endpoint Mapper (sometimes for WMI as well)
443 Other Hyper-V hosts that this host will replicate to; SCVMM Management IP Hyper-V Replica (only if using secure traffic) and System Center VMM
445 SMB 3 systems that present VM storage to this host; SMB 2+ targets with files this host needs to access, such as ISO; SCVMM library hosts; Live Migration target hosts if using SMB; other members of the same cluster; RDS broker Management IPs; cluster network IPs; RDS User Profile Disk share File copy; SMB access; Live Migrations in SMB mode; cluster communications; Cluster Shared Volume communications; RDS UPD host
3260 iSCSI Portals and Targets iSCSI discovery and initiator IPs iSCSI
6600 Other hosts this machine can Live Migrate to Live Migration IPs Live Migration when using standard TCP or compressed TCP modes

There isn’t much else to say with this table.

Other Hyper-V Related Traffic

Since I included port information for RDS, I might as well round it out with port information for RDS that doesn’t involve the hosts themselves. I’ll also include additional port information for System Center Virtual Machine Manager. While I’m at it, I’ll throw in some common ports just for the sake of completeness. I think the source/destination fields should be enough to help you figure out where to place these rules.

Other Hyper-V Firewall Rules
Port Target Source Purpose
All dynamic ports (49152-65535) All RDS hosts besides RDS broker RDS broker Server Manager and other tools that use Remote Procedure Call — the RDS broker is a central management hub
TCP/UDP 53 DNS servers Everyone DNS lookups
80 RDS Clients RDS web VDI’s web access is a standard IIS site
389 Domain Controllers Domain members Standard AD authentication
443 RDS Clients RDS web VDI’s web access is a standard IIS site
443 RDS Gateway RDS Clients Client-to-gateway connections handled via 443
443 RDS virtual machines RDS Clients If gateway is not used, clients authenticate directly to their own VMs on 443
686 Domain Controllers Domain members AD authentication using LDAPS; secure authentication is now also available on the 389 port
3389 RDS virtual machines in unmanaged pools RDS Broker Client-to-VM connectivity
3389 RDS Broker RDS Gateway Gateway facilitating of client-to-VM connectivity
3389 RDS virtual machines RDS Clients If an RDS gateway is not used, everyone is connected directly to his or her VDI virtual machine
UDP 3391 Same rules as 3389 Same rules as 3389 When this transport is enabled, higher-performing UDP is used for the connection. Duplicate all of the port 3389 rules to UDP 3391.
5504 RDS Broker RDS Web Hand-off from web authenticator to the RDS broker
5985 RDS Gateway RDS Broker RDS Broker control of RDS Gateway
8100 SCVMM Management stations Connect VMM console to VMM server service
8530 (default) Windows Server Update Services hosts All Windows/Windows Server/Hyper-v Server Windows Updates; may be configured to use another port

A few notes here:

  • I didn’t include all of the VMM rules. A more comprehensive list is available on the TechNet wiki. My real complaint with that list is that it does not include source/destination information and not all of the rules are obvious. For instance, you do need the Hyper-V hosts to be able to talk to the SCVMM server on port 443.
  • There is a similar TechNet wiki article for Remote Desktop Services, but the parts that aren’t difficult to sort out are just wrong and its overall state is such that, in good conscience, I cannot link it. Through some indirect channels, I have been left with the impression that the RDS team’s opinion on ever making that page useful or correct is “that’s not our job”. I have created the entries on these lists through Wireshark traces and observed trial and error. I can say that they have all worked just fine for me, but you might need to do some sleuthing of your own if you are doing some sort of configuration that I am not. PSS only has access to the same broken list so they will not be able to help you further, unless you don’t know how to use network traces or netstat to locate blocked ports.

 

 

Hyper-V and the Small Business: 9 Tips for Host Provisioning

Hyper-V and the Small Business: 9 Tips for Host Provisioning

The category of questions that I most commonly field are related to host design. Provisioning is a difficult operation for small businesses; they don’t do it often enough to obtain the same level of experience as a large business and they don’t have the finances to absorb either an under-provision or an over-provision. If you don’t build your host large enough, you’ll be buying a new one while the existing still has life in it. If you buy too much, you’ll be wasting money that could have been used elsewhere. Unfortunately, there’s no magic formula for provisioning, but you can employ a number of techniques to guide you to a right-sized build.

1. Do Not Provision Blindly

Do not buy a pre-packaged build, do not have someone on a forum recommend their favorite configuration, and do not simply buy something that looks good. Vendors are only interested in profit margins, forum participants only know their own situations, and no one can adequately architect a Hyper-V host in a void.

2. Have a Budget in Mind

Everyone hates it when the vendor asks, “How much do you want/have to spend?” I completely understand why you don’t want to answer that question at all, and I agree with the sentiment. We all know that if you say that you have $5,000 to spend, your bill will somehow be $5,027 dollars. Unless you have a history with the vendor in question, you don’t know if the vendor is truly sizing against your budget or if they’re finding the highest-margin solution that more or less coincides with what you said you were willing to pay. That said, even if you don’t give the answer, you must know the answer. That answer must truly be an amount that you’re willing to spend; don’t say that you’ll spend $5,000 if what you’re truly able to spend is $3,000. I worked for a vendor of solid repute that earned their reputation, so I can tell you from direct experience that it’s highly unlikely that you’ll ever be sold a system that is meaningfully smaller than what you can afford even if your reseller isn’t trying to oversell. Every system that I ever architected for a small business made some compromises to fit within budget. The more money they could spend, the fewer compromises were necessary.

3. Storage and Memory are Your Biggest Concerns

Part of the reason that virtualization works at all is because modern CPU capability greatly outmatches modern CPU demand. I am one of the many people that can remember days when conserving CPU cycles was important, but I can clearly see that those days are long gone. Do not try to buy a system that will establish a 1-to-1 ratio of physical CPUs to virtual CPUs. If you’re a small business that will only have a few virtual machines, it would be difficult to purchase any modern server-class hardware that doesn’t have enough CPU power. For you, the generation of the CPU is much more important than the core count or clock speed.

Five years ago, I would (and did) say that memory was your largest worry. That’s no longer true, especially for the small business. DDR3 is substantially cheaper than DDR2, and, with only a few notable exceptions, the average system’s demand on memory has not increased as quickly as the cost has decreased. For the notable exceptions (Exchange and SharePoint), the small business can likely get better pricing by choosing a cloud-based or non-Microsoft solution as opposed to hosting these products on-premises. Even if you choose to host them in-house, a typical server-class system with 32 GB of RAM can hold an 8 GB SharePoint guest, an 8 GB Exchange guest, and still have a good 14 GB of memory left over for other guests (assuming 2 GB for the management operating system). Even a tight budget for server hardware should be able to accommodate 32 GB of RAM in a host.

Storage is where you need to spend some time applying thought. For small businesses that won’t be clustering (rationale on my previous post), these are my recommendations:

  • Internal storage provides the best return for your dollar.
  • For the same dollar amount, prefer many small and fast disks over a few large and slow disks.
  • A single large array containing all of your disks is superior to multiple arrays of subsets.
  • Hardware array controllers are worth the money. Tip: if the array controller that you’re considering offers a battery-backed version, it is hardware-based. The battery is worth the extra expense.

Storage sizing is important, but I am intentionally avoiding going any further about it in this article because I want it to be applicable for as many small businesses as possible. There are two takeaways that I want you to glean from this point:

  • CPU is a problem that mostly solves itself and memory shouldn’t take long to figure out. Storage is the biggest question for you.
  • The storage equation is particular to each situation. There is no one-size-fits-all solution. There isn’t a one-sized-fits-most solution. There isn’t a typical, or a standard, or a usual, or a regular solution that is guaranteed to be appropriate for you. Vendors that tell you otherwise are either very well-versed in a particular vertical market that you’re scoped to and will have the credentials and references to prove it or they’re trying to get the most money out of you for a minimum amount of time invested on their part.

Networking is typically the last thing a small business should be worried about. As with storage sizing I can’t be specific enough to cover everyone that I’d like this post to be relevant to, but it’s safe to say that 2 to 6 gigabit Ethernet connections per host are sufficient.

4. Do not be Goaded or Bullied into 10 Gigabit Ethernet

I won’t lie, 10 GbE is really nice. It’s impressive to see it in operation. But, the rest of the truth is that it’s unnecessary in most small businesses, and in lots of medium businesses too. You can grow to a few thousand endpoints before it even starts to become necessary as an interswitch backbone.

A huge part of the reasoning is simple economics:

  • A basic business-class 20-port gigabit switch can be had for around $200 USD. You can reasonably expect to acquire gigabit network adapters for $50 or less per port.
  • A basic 12-port 10GbE switch costs at least $1,500 USD. Adapters will set you back at least $250 per port.

When you’re connecting five server-class hosts, $1,500 for a switch and $500 apiece for networking doesn’t seem like much. When you’re only buying one host for $5,000 or less, the ratio isn’t nearly as sensible. That price is just for the budget equipment. Since 10GbE adapters can move network data faster than modern CPUs can process it, offloading and VMQ technologies are quite important to get the most out of 10GbE networking. That means that you’re going to want something better than just the bare minimum.

What might even be more relevant than price is the fact that most people don’t use as much network bandwidth as they think they do. The most common tests do not even resemble typical network utilization, which can fool administrators into thinking that they don’t have enough. If you need to verify your usage, I’ve written an article that can help you do just that with MRTG. This leads into a very important point.

5. You Need to Know What You Need

Unless you’re building a host for a brand-new business, you’ve got an existing installation to work with. Set up Performance Monitor or any monitoring tool of your choice and find out what your systems are using. Measure CPU, disk, memory, and networking. Do not even start trying to decide what hardware to buy until you have some solid long-term metrics to look at. I’m surprised at how many messages I get asking me to recommend a hardware build that have little or no information about what the environment is. I’m guessing that the questioners are just as surprised when I respond, “I don’t know.” It doesn’t take a great deal of work to find out what’s going on. Do that work first.

6. Build for the Length of the Warranty

Collecting data on your existing systems only tells you what you need to know to get through the first day. You’re probably going to need more over time. How much more depends on your environment. Some businesses have reached equilibrium and don’t grow much. Others are just kicking things off and will triple in size in a few months. Since those truly new environments are rare, I’m going to aim this next bit at that gigantic majority that is building for the established institutions. Decide how much warranty you’re willing to buy for the new host and use that as your measuring stick for the rest of it. How you proceed depends upon growth projections:

  • If system needs won’t grow much (for example, 5-10% annually), then build the system with a long warranty period in mind. If the business has been experiencing a 5% average annual growth rate and is currently using 300 GB of data, a viable option is to purchase a system with 500 GB of usage storage with a 5-year warranty.
  • If system needs will grow rapidly, you have two solid options:
    • Buy an inexpensive system with a short warranty (1-3 years). Ensure that it’s understood that this system is not expected to live long. If decision-makers appear to be agreeing without understanding, you’re better off getting a bigger system.
    • Buy a system that’s a little larger with a longer warranty (5 years). Plan a definite growth point at which you will scale out to a second host. Scaling out can become more than twice as expensive as the original, especially when clustering is a consideration, so do not take this decision lightly.

Most hardware vendors will allow warranty extensions which gives you some incentive to oversize. If you make a projection for a five-year system and it isn’t at capacity at the end of those five years, extending the warranty helps to maximize the initial investment.

In case it’s not obvious, future projections are much easier to perform when you have a solid idea of the environment’s history. There’s more than one reason that I make such a big deal out of performance monitoring.

7. Think Outside the One Box

Small businesses typically only need one physical host. There isn’t any line at which you cross over into “medium” business and magically need a second host. There isn’t any concrete relationship between business size and the need for infrastructure capacity. Just as I preach against the dangers of jumping into a cluster needlessly, I am just as fervent about not having less than what is adequate. Scaling out can undoubtedly be expensive, but when it’s time, it’s time.

Clustering isn’t necessarily the next step up from a single host. Stagger your host purchases across years so that you have an older system that handles lighter loads and a newer system that takes on the heavier tasks. What’s especially nice about having two Hyper-V hosts is that you can have two domain controllers on separate equipment. Even though I firmly stand behind my belief that most small businesses operate perfectly well with a single domain controller, I am just as certain that anyone who can run two or more domain controllers on separate hosts without hardship will benefit from the practice.

8. Maybe Warranties are Overrated

I’ve been in the industry long enough to see many hardware failures, some of legendary quality. That doesn’t change the fact that physical failures are very nearly a statistical anomaly. I work in systems administration; my clients and workers from other departments never call me just to be social. Anyone in my line of work deals with exponentially more failures than anyone outside my line of work. So, while I am probably always going to counsel you to spend extra so that you can get new or something that is new enough that you can still acquire a manufacturer’s warranty on it, I can also acknowledge that there are alternatives when the budget simply won’t allow for it.

In my own home, most of the equipment that we use is not new. As a technophile, I have more computers than people, and that’s before you start counting the devices that don’t have keyboards or the units that are only used for my blogging. I rarely buy anything new. I am unquestionably a fan of refurbished and cast-off systems. It’s all very simple to understand: I want to own more than I can technically afford to own, and this practice satisfies both my desire for tech and my need for frugality. Is that any way to run a business? Well…

Cons of Refurbished and Used Hardware

One the one hand, no, this is not a good idea. If any of this fails, I have to either repair it, live without it, or replace it. If you don’t have the skills for the first, the capacity for the second, or the finances for the third, that leaves your business in the lurch. If you’d have to make that choice, then no, don’t do this. Another concern is that if you’re doing this to be cheap, a lot of cheap equipment doesn’t meet the criteria to be listed on http://www.windowsservercatalog.com and might be more trouble than the savings is worth. And of course, even if it’s good enough for today’s version, it might not work with tomorrow’s version.

For another thing, I’ve seen a lot of really cheap business owners use equipment that they had to repair all the time and that was so inefficient that it impacted worker productivity. That sort of thing is a net loss. Avoid these conditions, even if it means spending more money. Remember what I said earlier about compromises? Sometimes the only viable compromise is to spend more money on better hardware.

If you go the route of having hardware that doesn’t carry a warranty, you need to be prepared to replace it at all times. Warranty repairs are commonly no longer than next-business-day in this era. Buying replacement hardware could have days or even weeks of lead time. Having replacement hardware on hand can cost more than just buying new with warranty.

Pros of Refurbished and Used Hardware

On the other hand, I spent less to acquire many of these things than their original owners did on their warranties, and, with the law of averages, most of my refurbished equipment has never failed. I quite literally have more for less. Something else to remember is that a lot of refurbished hardware is very new. Sometimes they’re just returns that can no longer be sold as “new”. You can often get original manufacturer warranties on them. The only downside to purchasing that sort of hardware is that you don’t get to pick exactly what you want. For the kind of savings that can be had, so what?

In case you’re curious, all of the places that I’ve worked pushed a very hard line of only selling new equipment. “Used” and “refurbished” carry a very strong negative connotation that no one I worked for wanted to be attached to. However, I didn’t work for anyone that would turn away a client that was using used or refurbished equipment that they acquired independently. I’ve encountered plenty of it in the field. It didn’t fail any more often than new equipment did. I’ll say that I do feel more comfortable about “refurbished” than “used”. I also know what it’s like to be looking at a tight budget and needing to make tough decisions.

I will say that I would prefer to avoid used hardware for a Hyper-V host. I understand that it can be enticing for the very small business budget so I will stop short of declaring this a rule. It’s reasonable to expect used hardware to be unreliable and short-lived. Used hardware will consume more of your time. Operating from the assumption that your time has great value, I encourage you to consider used hardware as a last resort.

9. Architect for Backup

I expect point #8 to stir a bit of controversy. I fully expect many people to disagree with any notion of non-new equipment, especially those that depend on margins from sales of new hardware. I don’t mind the fight; until someone comes up with 100% failure-free new hardware, there will never be a truly airtight case for only buying new.

If you want to give yourself a guaranteed peace of mind, backup is where you need to focus. I may not know the statistics around failures of new versus used or refurbished equipment, but I know that all hardware has a chance of breaking. What doesn’t break due to defect or negligence can be destroyed by malice or happenstance, so you can never rely too much upon the quality of a purchase.

What this means is that when you’re deciding how many hard disks to buy and the size of the network switch to plug the host in to, you also need to be thinking about where you’re going to copy the data every night. External hard disks are great, as long as they’re big enough. Offsite service providers are fine, as long as you know that your Internet bandwidth can handle it. If you don’t know this in advance, you run the risk of needing to sacrifice something in your backup rotations. I have yet to see any sacrifice in this aspect that was worth it.

Page 1 of 3123