Choosing a Hyper-V Installation Option – Native or as a Role in Windows Server Core or Full

Save to My DOJO

Choosing a Hyper-V Installation Option – Native or as a Role in Windows Server Core or Full

One of Hyper-V’s unique attributes is that it has dramatically different deployment options. You can install it natively directly to host hardware, or you can install a copy of Windows Server and enable Hyper-V as a role. Within the Server option are two more choices: Full or Core. There are perfectly valid reasons to choose any of these three deployment options.  The decision is fairly permanent, though, so take the time to make an educated decision prior to deployment.

Hyper-V Installation Differences and Similarities At a Glance

Features

Hyper-V Installed Natively

Hyper-V Installed as a Role

Type 1 Hypervisor

clip_image001[38]

clip_image001[39]

High VM Performance

clip_image001[40]

clip_image001[41]

Hard Drive Requirements

clip_image002[18]

clip_image002[19]

Domain Membership

clip_image001[42]

clip_image001[43]

Guest Virtualization Licensing Rights

clip_image002[20]

clip_image002[21]

Host Licensing Rights

Free license

Usually covered by one of the guest VM licenses

RemoteFX

clip_image001[44]

clip_image003[26]
Supported in Full, not in Core

Windows GUI

clip_image004[6]

clip_image003[27]
Supported in Full, not in Core

Run GUI applications

clip_image003[28]

clip_image003[29]
Supported in Full, partially in Core

Remote Management

clip_image003[30]
Only “Server Manager” doesn’t work

clip_image001[45]

Clustering

clip_image001[46]

clip_image003[31]
Not supported in Standard Edition

 

What Doesn’t Matter

Before getting into the differences, be aware of the things that will be the same in all three deployment types.

  • Performance:  For all but the densest installations, there is no meaningful difference in guest virtual machine performance regardless of which method you choose. The extras needed for the GUI in a full Windows deployment and for the extra capabilities of either Server installation have an extremely minimal impact and will lose to Hyper-V if resources are in contention.
  • Hard Drive Space: Hyper-V itself doesn’t need much space, but no matter which way you go, Windows Server is the management operating system. You must install Hyper-V to a device that has enough room.
  • Domain Membership: All three types can be a member of your domain for security continuity.
  • “Type 1” Hypervisor Status: Hyper-V always operates as part of the base kernel and never becomes a Type 2 hypervisor even when it is run as a role within Server.
  • Guest Virtualization Licensing Rights:The different editions of Windows Server come with separate host and guest virtualization rights.  Host licenses are assigned by motherboard (Standard and Enterprise) or by CPU socket (Datacenter). Virtualization rights are assigned with the host license. For each Standard license assigned to a host, you can install one virtualized copy of Windows Standard edition. For each Enterprise license assigned to a host, you can run four virtualized installations of Windows Enterprise or Standard edition on that host. For each CPU that is assigned a Datacenter license, you can install as many virtualized copies of Datacenter, Enterprise, and Standard edition as you want. The important thing is that these virtualization rights apply no matter what deployment method you use, even if you choose to use a non-Microsoft hypervisor. Even if you don’t actually install any copy of Windows Server to the assigned host, the physical licenses must be reserved for it and not installed anywhere else.
    • Example: You want to run three copies of Windows Standard Editions and two copies of Windows Enterprise edition in your virtualized environment. The optimal licensing purchase is one copy of Standard Edition and one copy of Enterprise Edition and assign them to the physical host (there is no actual activity involved here, you just need to ensure that the licenses you purchase are not used anywhere else). The Enterprise Edition covers the two Enterprise VMs and two of the Standard VMs while the Standard license covers the final Standard VM.
    • If you place your hosts in a cluster, you must have enough licenses assigned to each host to apply to every VM that might run on it at any time, or you will be out of compliance. You cannot split the four licenses from Enterprise or the unlimited licenses from Datacenter across motherboards or sockets, respectively. However, if you operate in a pure failover environment in which VMs will not run on a particular host unless other host(s) have failed, you only need to ensure you have enough transferable licenses (non-OEM). So, continuing with the original scenario, if you add another host but never run anything on it unless the primary fails, you don’t need any more licenses. If you add another host for load-balancing, you only need to purchase one more Enterprise license for a total of two Enterprise licenses and one Standard license (because if ALL the VMs move to the second host, the Standard license is transferable; any other combination will be covered by the two Enterprise license assigned on both hosts).
    • If you don’t use Datacenter Edition licensing, you will almost undoubtedly wind up with more physical host licensing rights than you have hosts. These licenses cannot be transferred to another physical host without their attendant guest virtualization licensing rights being transferred as well.  From the original example, you cannot take the Enterprise or Standard physical license and install on another physical unit without losing the virtualization rights on the original hardware.  Simply put: Guest licensing rights follow physical licensing rights at all times.

What Really Matters

Fortunately, there are only a few critical differences to consider.

  • Host Licensing Rights: A native installation of Hyper-V requires no license of any kind. Any installation of Windows Server to physical hardware must be licensed it appropriately (Standard, Enterprise, or Datacenter). In most cases, the host license will be automatically covered by purchase of guest OS licenses (see the Guest Virtualization Licensing Rights sub-section above), but this must be considered.
  • Clustering Capabilities:  Windows Server Standard Edition cannot join a cluster. If you deploy either Full or Core on Standard Edition, it will always be a standalone host.  Native Hyper-V, Windows Server Enterprise, and Windows Server Datacenter can all join a cluster.
  • RemoteFX: RemoteFX works on guests of a native Hyper-V installation or when Hyper-V is used as a role in a Full installation of Windows Server. It will not work for guests of Hyper-V installed as a role on Server Core.

Non-Critical Differences

  • User interface: A Full installation of Windows includes the complete Windows Explorer GUI, and accordingly, other applications that rely on that interface, such as Internet Explorer, MMC, and several Control Panel items. It adds a tiny amount of overhead that is going to be insignificant in all but the most demanding and tight deployments. It adds to the attack surface of the deployment, although it would be unfair to overstate this; successful attacks against Explorer itself have decreased dramatically and can be almost entirely eliminated by careful hardening. Using a Full installation of Windows can greatly ease initial deployment for administrators, but since the graphical tools to manage Hyper-V can be run remotely from a workstation or another server, day-to-day operations aren’t significantly easier. Additionally, learning the command-line for the purposes of setting up and maintaining native Hyper-V or Server Core is not overly difficult and there are plenty of guides available for assistance. Many graphical tools will run under Core and native Hyper-V; notable members of this group are the Hyper-V Guest Console, Core Configurator (http://coreconfig.codeplex.com/) and an iSCSI management interface (iscsicpl.exe).
  • Hypervisor Upgrades: When Hyper-V 2012 is released, there won’t be any licensing requirements to consider if you have a native installation.  You can make the switch as soon as you are comfortable doing so.  If you don’t upgrade any of your guests to the latest OS, then you need to purchase nothing.
  • Remote Management and Connectivity: The differences here are so slight that it almost fits under “What Doesn’t Matter”. All three types can run as a RDP host. MMC consoles like Computer Management, Services, Event Viewer, Hyper-V Manager, etc. can connect to any of the three types. There is one exception: the Server Manager MMC console cannot be used to remotely manage a native installation of Hyper-V, even if you add the necessary features. You’ll need to use the individual MMCs that Server Manager bundles.
  • Role Support: Server Core supports almost all the same roles as a Full installation does. Native Hyper-V supports very few. As a best practice, a Hyper-V server should only be a Hyper-V server. Mixing roles is always ill-advised for several reasons, but it’s worse with Hyper-V because of the virtual machines. If you need to reboot your Hyper-V server because it’s also your Exchange server and you’re rolling out an Exchange patch, that impacts every VM on that Hyper-V server; if that Exchange Server is attacked, the Hyper-V server is also being attacked by association and every VM will suffer along with it. Of course, the real world of budgets and licensing and other limitations will always play a factor, and you may have a legitimate need to mix roles. The most commonly shared role is that of domain controller. A native installation of Hyper-V cannot operate as a domain controller, so if this is a requirement, you’ll need to use one of the Windows deployment methods.  You are encouraged to explore every possible avenue to avoid mixing roles with Hyper-V.
  • Application Support: It is a common myth that Core cannot run GUI applications. It is certain that it cannot run as many as a Full installation, but it has surprisingly few limitations. It will not run any MMC snap-ins or applications dependent on the presence of explorer.exe. You can install the various levels of the .Net Framework and run most .Net-dependent applications.  A native installation of Hyper-V behaves the same way as Core in this regard.

image

Practical Guidance

There is no magic formula to tell you exactly what to do, even if you’re just trying out Hyper-V. A sensible recommendation is to make a native deployment your preferred choice, a Core deployment your second choice, and a Full deployment your final option. Give a native installation a thorough shakedown. If you find that it has a limitation that a Server installation would solve and you just can’t find any alternative, move up to Core and repeat the trial. This is also a good approach for a more casual investigation. If you become accustomed to using Hyper-V within a GUI environment, it will forever be your preferred way to work with Hyper-V and you’ll always have a harder time managing it from the command-line than you would have if you’d simply started with the command-line.

Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

8 thoughts on "Choosing a Hyper-V Installation Option – Native or as a Role in Windows Server Core or Full"

  • Joel Carter says:

    Thanks for the post. Interesting that RemoveFX isn’t supported in guests under a Core host. For me that would be the only reason not to use it over a role install. You don’t mention the advantage that Core has related to updates – there are significantly less compared to native which means more uptime for your host.

  • Chris Knight says:

    Hyper-V Server can be managed using Server Manager from a Windows 7/Windows Server 2008 R2 machine when both systems are in a workgroup using the instructions here:
    http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/11/configuring-remote-management-of-hyper-v-server-in-a-workgroup.aspx

  • Does anyone have experience on using Core config to manage Hyper-V 2102 Beta?

    When i tried to run the program all i get is a disappearing black screen!

    Any help would be highly appreciated.

    Regards

  • Chennai MCSE says:

    Hi,

    To find the names for different modules in PowerShell 3, use the PowerShell cmdlet “Get-Module -ListAvailable” (without Quotes)

    After finding the module name, again use the PowerShell Get-Command -Module to get the related cmdlets for that module.

    For Example, to find the different cmdlets related with Hyper-V module, use the following PowerShell cmdlet

    Get-Command -Module Hyper-V

    Thanks a lot for the wonderful tech site…

  • Jon Hodges says:

    It would be very helpful if this article’s title included the fact that this is written for Server 2008. At the very least, the published date ought to include the year. Otherwise, the licensing information is misleading (OK, wrong!).

    -jonH

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.