Cloud Computing with Hyper-V 3.0

Organizations anxious to reap the benefits of cloud computing but reluctant to give up control of critical resources are building private clouds. Deploying a private cloud provides cloud-like functionality in a secure on-premises environment. But when it comes to actually building that private cloud, many administrators are left scratching their heads.

One problem is a private cloud seems to mean something different to almost everyone. So, the first step in building a private cloud is to define some goals and expected functionality for your environment. After doing so, you can determine how to use Microsoft Hyper-V to reach those goals.

A private cloud must possess the following three characteristics or capabilities:

1. A private cloud should treat server hardware as a pool of shared resources.
2. A good private cloud should include a self-service function, meaning an authorized end user can request resources and deploy preconfigured virtual machines (VMs) with minimal IT involvement.
3. A private cloud should provide administrators with a way to track which resources they are using. Using chargeback or showback is useful for capacity planning and to track costs.

f you consider these three primary characteristics of private cloud, then Hyper-V 3.0 does not build a private cloud; the software does not include an automated process. Still, it’s possible to build a fully functional private cloud based on Hyper-V.

Resource pooling in a private cloud

The first requirement of building a private cloud involves treating physical server hardware as a pool of resources an admin can dynamically provision. Hyper-V 3.0 actually makes it relatively easy to meet this. Here are some examples of how Hyper-V can pool these resources:

Hyper-V 3.0 separates the Startup Memory setting from the Minimum Memory setting, allowing some of the startup memory to be reclaimed once the VM becomes idle. And this enables far greater VM density. On the flip side, Hyper-V 3.0 allows for NUMA spanning — a single VM can access memory from multiple NUMA nodes. In this instance, the VM can access more memory than would be otherwise possible.

• Network: VMs connect to a virtual network rather than attaching directly to a physical network. This virtual network is based on the use of a virtual switch that usually connects to a physical network interface card (NIC).
  In Hyper-V 3.0, the virtual switch is extensible, which is useful for network management and monitoring. Hyper-V can make use of virtual LANs to isolate certain types of network traffic to a dedicated virtual network. At the physical level, multiple NICs can be teamed together to form a single logical NIC. This logical NIC is fault tolerant and provides higher network bandwidth than would be possible using a single physical NIC.
• Storage: Hyper-V has always supported the use of thinly provisioned virtual hard drives, but combining Hyper-V 3.0 with Windows Server 2012 makes it possible to virtualize physical storage. Windows Server 2012 offers a new feature called Storage Spaces that allows you to add multiple physical hard disks to a storage pool. This storage pool can provide the required fault tolerance and capacity to the entire virtualization infrastructure.
• Memory: The concept of dynamic memory was first introduced in Hyper-V 2.0, but has been enhanced in Hyper-V 3.0. In Hyper-V 2.0 the Minimum Memory setting had to meet the amount of memory a VM required at startup. However, VMs often consume more memory at startup than they do when in an idle state.
  Hyper-V 3.0 separates the Startup Memory setting from the Minimum Memory setting, allowing some of the startup memory to be reclaimed once the VM becomes idle. And this enables far greater VM density. On the flip side, Hyper-V 3.0 allows for NUMA spanning — a single VM can access memory from multiple NUMA nodes. In this instance, the VM can access more memory than would be otherwise possible.

Microsoft Hyper-V 3.0 and self-service provisioning

The second requirement to building a private cloud is that authorized users should be able to request and provision resources with minimal IT involvement. This functionality is not built into Hyper-V, however; Microsoft offers an add-on for System Center Virtual Machine Manager called the Self Service Portal.

The Self Service Portal acts as a Web interface that automatically deploys preconfigured VM user requests. You will also need Microsoft’s Deployment Toolkit, which helps you create VM images users can automatically deploy using the Self Service Portal.

Tracking resource use with the Self Service Portal

The final requirement of a private cloud is the ability to track resource consumption. The Self Service Portal in Hyper-V 3.0 includes a chargeback mechanism. This mechanism lets you specify a price for various resources and allocate a cost per user or a cost per department based on the resources consumed when a user requests a VM.

Virtual Networking in Microsoft Hyper-V

Introduction

Networking in Hyper-V is sort of interesting for those who are used to physical networking or are used to the way networking is implemented in VMware. With Hyper-V, the guest operating systems never have direct access to the hardware, and the Hyper-V management interfaces control the traffic moving through the physical and virtual interfaces.

Hyper-V has a Virtual Network Manager. The Virtual Network Manager is responsible for creating and controlling virtual switches. There is no limit on the number of virtual switches you can create – depending on the type of virtual network you are working with. For example, external virtual networks are basically on physical NICs, so you can only have the number of external networks that is the same as the number of physical NICs.

The concept of a virtual network is an important one to understand. Consider a virtual network to be like a switch, but instead of a physical switch, it’s a virtual switch. All the virtual machines that connect to the same virtual network switch are connected to the same switch. Each virtual switch is logically isolated from all other virtual switches. If you want hosts that are connected to one virtual switch to communicate with hosts that are on another virtual switch, you can create a virtual router, VPN server, firewall or similar device to those you would have on a physical network. It’s a good idea to create different virtual switches if you have scenarios where you need to have network isolation similar to what you would have on a physical network, where the different segments are separated by firewalls or some other access control device.

Virtual Network Types

There are three types of virtual networks that you can connect to in Hyper-V:

• Private Virtual Network
• Internal Virtual Network
• External Virtual Network

A Private Virtual Network is a virtual switch to which only virtual machines can connect. Guest operating systems that are connected to the same Private Virtual Network can communicate with each other, but they cannot communicate with the Host operating system and the Host operating system cannot connect to the VMs on the Private Virtual Network. Private Virtual Networks are great if you need total isolation from all other Virtual Networks, but they can sometimes be problematic if you need to copy files to the virtual machines, since there is no connectivity to any physical network or to the Host operating system. In this scenario, you can create a virtual machine that functions as a firewall or a router, and connect one virtual network adapter to the Private Virtual Network and another virtual network adapter to the physical network (through an External Virtual Network, which we’ll talk about in just a bit).

An Internal Virtual Network is similar to a Private Virtual Network in that it isn’t bound to any physical NIC. The Internal Virtual Network is an isolated virtual switch like the Private Virtual Network, but in the case of the Internal Virtual Network, the Host operating system has access to the guest virtual machines through the Internal Virtual Network virtual switch. However, there is no DHCP-like functionality with this virtual switch (as there is with some instantiations of VMware Workstation), so if you want to communicate with virtual machines that are connected to the Internal Virtual Network switch, you are going to need to assign an IP address to the virtual NIC that’s associated with that Internal Virtual Network for the Host operating system that is valid on the virtual network to which you are trying to connect.

An External Virtual Network is different from the other Virtual Networks because this type of virtual network is associated with physical network adapters. You can have one External Virtual Network for each physical NIC that’s installed on the Hyper-V server. The External Virtual Network switch will actually appear to take the place of the physical NIC on the Hyper-V server – so that if you were to look at the configuration of the former NIC, it would appear to not have any IP addressing assigned to it. Instead, a virtual NIC is added to the Network Connections window and that virtual NIC is connected to the External Virtual Network switch, and it is that virtual NIC that has the IP addressing assigned to it that allows it to communicate with the physical network.

There are some important things you should know about Virtual Networks and Virtual NICs before you get started working with them in Hyper-V:

• If you connect to the Hyper-V server over the network using RDP, the network connection that you used before will be gone, and you will probably need to visit the Hyper-V server and configure the new virtual External NIC at the server in order to regain connectivity
• You can not create an External Virtual Network based on a wireless NIC (which is a big drawback, in my opinion, as you are able to do this with VMware)
• You can tell the name of the Virtual NIC associated with the virtual switch because the NIC and switch will have the same name; the only difference is that the virtual switch won’t have any IP addressing information bound to it and the NIC will
• Because of the connectivity issue I mentioned above, it’s a good idea to have at least two physical NICs on your Hyper-V server. That way, you can use one NIC as a dedicated management interface for the Host operating system, and assign an External Virtual Network to the other NIC.

Virtual NICs

Hyper-V enables support for two types of virtual NICs:

• Legacy NICs
• High Speed NICs

Each virtual machine can have up to 12 virtual NICs attached to it;more specifically, each can have up to 8 high speed NICs and up to 4 legacy NICs.

A legacy NIC emulates a physical NIC (DEC 21140 NIC) and will work right away without the need to install any additional software since most operating systems will support this NIC right out of the box. The legacy NIC also supports PXE for network based operating system installation.

You can use the legacy NIC to get you up and running so that you have network connectivity before you install the Hyper-V integration services. However, in some cases you will have to install integration services, such as in the case of Windows XP and Windows Server 2003 64-bit operating systems, which don’t include support for the legacy NIC emulation of the DEC virtual NIC.

The high speed NIC is just that – a high speed NIC, and as you might guess, it will give you the best performance. However, in order to make use of the high speed NIC, you will need to install the Hyper-V integration services after the guest operating system is installed.

Virtual NICs support VLAN tagging with VLAN ID numbers assigned to them and Virtual Networks can be assigned VLAN IDs.

Some things that you should keep in mind regarding VLAN configuration and virtual networks and NICs:

• The physical NIC on the Hyper-V server needs to support VLAN tagging and the VLAN feature needs to be enabled on the physical NIC.
• However, you should not set a VLAN ID on the physical NIC. Instead, configure it on the virtual NIC that’s associated with that External Network switch or to the virtual machines themselves.
• The virtual machine will use the VLAN ID that is assigned to its virtual NIC. The VM isn’t aware of the ID that’s assigned to the virtual switch.

Hyper-V Networking Recommendations

The following represent a collection of recommendations and best practices so that you can get the most out of your Hyper-V networking environment:

• As mentioned earlier, you should have at least two physical NICs on your Hyper-V server, so that there’s one for management of the Host operating system and one that you can assign to an External Virtual Network
• You should use Private Virtual Networks when you want complete isolation from both the Host operating system and the physical network
• You should use the Internal Virtual Network when you need to transfer files between the Host operating system and the virtual machines
• You can dynamically unplug and plug virtual machines into different virtual networks. You do not have to shut down the virtual machine in order to change its network connection
• If you want to segment your virtual networks, you can create a virtual switch for each network (that is to say, create a Virtual Network for each network) and then connect them using a TMG firewall or Windows RRAS virtual machines
• Remember to assign the Host operating system’s Internal Virtual NIC a valid IP address so that it can communicate with VMs on the same Internal Virtual Network
• Some virtual machines will require large amounts of bandwidth to communicate with the physical network. In this scenario, you should configure a dedicated External Virtual Network for these NICs and you should not connect any other virtual machines to them
• If you want to put a Hyper-V server on the edge of your network, make sure that the Host operating system’s virtual NIC on the untrusted network does not have valid IP addressing information. This will prevent intruders from connecting to the Host operating system over the Internet

Summary

Hyper-V networking provides you with a way to customize your virtual network environment. You can use the various Virtual Networks to control the level of connectivity the virtual machines have with one another, as well as connectivity to the Host operating system and the physical network. However, before you start working with Hyper-V virtual networks, you need to have an understanding of how they work and some of the key features and limitations imposed by these networks. In a future article, we’ll go through a walk-through on configuring and managing virtual networks and see how they work with a virtual server that has four physical NICs.