In this article I would like to share the new things in Windows Server 2012 that grabbed my particular attention. It’s not a full list of the new features, which you can find on the Microsoft official site. It’s more like a summary of the more advanced and intriguing new features.
Windows Server 2008 R2 supported live migration, but only if the virtual hard disk’s location remained the same, i.e. SAN. What Windows Server 2012 brings to the scene is the ability to move a virtual machine outside a cluster environment to any other Hyper-V host. You can even move several machines at the same time. The only thing you would need is a shared folder accessible from both locations and then you could move the storage (storage migration) of a virtual machine to a new one. Windows Server 2012 even offers you the ability to do a “Shared Nothing” live migration, meaning the ability to migrate a virtual machine from one host to another, even if they have no connectivity between themselves other than the simple network cable.
In a typical virtualization infrastructure there are multiple virtual machines sharing the same physical network card. In periods of heavy loads one virtual machine can manipulate the traffic if it needs it, leaving insufficient traffic for the rest of the machines. In Windows Server 2008 R2 you were able to set the maximum bandwidth for each virtual machine, meaning that they couldn’t occupy more of their allocated bandwidth, even if they needed to. However, it was inefficient in situations when the other virtual machines didn’t actually need the rest of the bandwidth. Setting a minimum bandwidth in Windows Server 2012 allows you to specify how much bandwidth each virtual machine needs in order to function. However, these constraints are applied only when there is a conflict in the bandwidth needs of virtual machines. If there is free bandwidth each virtual machine may use it until other virtual machines that are under their minimum bandwidth need it.
Let’s say we have a 1 Gigabit Ethernet card. We specify the minimum bandwidths for Virtual Machine (VM) 1, VM2, and VM3 to be respectively 500 Mb, 300 Mb, and 200 Mb (the sum can’t exceed the total bandwidth of the Ethernet card). In a moment of less activity from VM2 and VM3, VM1 uses 700 Mb of the available bandwidth, VM2 and VM3 use 100 Mb each. However, in the next moment a transaction is processed to VM2 and it needs all its available bandwidth. When that happens, VM2 will first occupy the available 100 Mb, but because it still needs more bandwidth and it’s under its minimum bandwidth of 300 Mb, V1 (as it exceeds its minimum bandwidth) will have to give VM2 100 Mb more.
What it allows you to do is to have multiple virtual networks, possibly with the same IP address schemes, on top of the same physical network. It is really useful for cloud services providers. However, it can be used in businesses as well, for example when HR or Payroll traffic should be totally separated from the rest of the traffic. It also allows you to move virtual machines wherever you need them, despite the physical network, even to the cloud. For this to be possible each virtual machine has two different addresses for each network adapter. One is used for communication with the rest of the virtual machines and hosts in that network and is called Client Address. The other one is called Provider Address and it’s used for communications on the physical network only. These addresses are given so that different clients/departments have specific addresses so that the provider knows which traffic comes from which client/department. This way, the traffic is completely isolated from any other traffic on the physical network.
It allows you to easily do your capacity planning, because it collects information for the use of resources of a virtual machine throughout a period of time. Furthermore, Windows Server 2012 introduces the concept of resource pools. They combine multiple virtual machines belonging to one specific client or used for one specific function and the resource metrics are collected on a per user/function basis. This technique is helpful for IT budgeting needs and for billing customers. The metrics usually being collected are: Average CPU use (for a selected period of time); Average memory use; Minimum memory use; Maximum memory use; Maximum disk allocation; Incoming network traffic; Outgoing network traffic.
A rogue DHCP server is a fake server which is connected to the network, collects DHCP server requests and responds with incorrect addressing information. Active Directory protects its DHCP service by not allowing other DHCP servers to operate on the network until they are authenticated. However, this does not apply for non-Microsoft-Windows DHCP servers. They could still connect to the network and give addresses. Windows Server 2012 limits this by allowing you to specify which ports can have DHCP servers attached. So if the intruder is attached to any other port, its DHCP fake server packets would be dropped.
They are mainly used when you need point-in-time recovery in case of an error. For example, when you apply a service pack on a production server, you may want to give yourself a backdoor in case something bad happens. You take the snapshot before the service pack installation and if needed, you recover the server with it. What happens if you don’t need it? You’ve monitored the server for a while and everything seems normal after the patch? You don’t need the screenshot anymore. However, in Windows Server 2008 R2 you couldn’t just get rid of it. You would have to pause the virtual machine for a while, making it inaccessible. Windows Server 2012 has a new feature, called Hyper-V Live Merge, which allows you to release the snapshot while the machine continues to run.
Stay tuned to Monitis for our future articles on Windows Server 2012. We will take a deeper look into these and some more advanced new features.