What’s new in Windows Server 2008 R2? Ravikanth Chaganti

About me Lead engineer, Windows Server OS group at Dell Blog @ http://www.ravichaganti.com/blog Author of HVS2008 UI tool @ http://hvs2008ui.codeplex.com Ravikanth@ravichaganti.com

Agenda Windows Server roadmap Windows Server 2008 R2 Changes in R2 Hyper-V improvements Power Management Improved Remote Management Deployment References Q & A

Windows Server roadmap

Windows Server 2008 R2 Currently in public beta phase No 32-bit or x86 version of OS Minimum / recommended system requirements are same as Windows Server 2008 Will have the following editions Standard Enterprise Data center Web Hyper-v Server 2008 R2 (based on Standard)

Changes in R2 Hyper-V improvements Power Management Live Migration and Cluster Shared Volumes (CSV) Dynamic Storage Second Level Address Translation (SLAT) Jumbo frames Virtual Machine Queues Power Management Core Parking Processor P-state support Improved Remote Management Server Manager Console PowerShell 2.0 PowerShell ISE Deployment Native VHD & VHD boot support WDS improvements to support native VHD boot There are many changes to R2 operating system. I have listed a few significant ones here There are many changes to Terminal services and Web technologies within R2 We will discuss the highlighted topics in detail through this session and briefly touch upon the remaining topics now Dynamic Storage You can now hot add/remove VHDs and pass through disks to and from a running VM. Supported only using virtual SCSI controller Jumbo Frames Jumbo Frames add the same basic performance enhancements to virtual networking. That includes up to 6 times larger payloads per packet, which improves not only overall throughput but also reduces CPU utilization for large file transfers. SLAT Uses processor features like Intel EPT (Enhanced page tables) or AMD RVI (Rapid Virtualization indexing) or NPT (Nested Page tables); Processor resources spent in translating guest memory addresses to physical and vice versa is saved Processor P-States P states are the processor performance states as per ACPI specification; R2 can adjust P-states and subsequently adjust power consumption GPO can be used to configure how power states are used

R2: Live migration Most highly anticipated feature in Hyper-V v2 Eliminates the limitations of Quick Migration Move running VMs from one host to another with no disruption of service Better agility Increased productivity Live migration can happen only between hosts with processors from same manufacturer Intel to Intel or AMD to AMD can happen; Intel to AMD is not possible Support Supported only on Enterprise and Datacenter editions Hyper-V Server 2008 R2 will have support for Live migration Supports up to 16 nodes per cluster Quick migration involved down time because of the way it implemented moving VMs from one host to another. In QM, VM is first paused and then moved to the destination and resumed there. This caused up to 6mins of downtime in a few scenarios Each disk is owned by a single node at any given point in time Better Agility You can move VMs based on the work load scenarios, available resources and achieve optimal consolidation Using SCVMM 2008 R2, you can policies created for moving VMs around automatically and transparent to the end user Increased productivity Scheduled maintenance of physical hosts can be done without really impacting the workload inside a VM.

R2: Live migration How it works? (animation) You can use failover cluster manager to initiate VM live migration SCVMM 2008 R2 is another option; and of course, you can script the migration process using WMI or PowerShell This slide shows various steps that take place when migrating a VM from One host to another Step1 A TCP connection is created between source and destination hosts Configuration data is moved to the destination host; essentially creating a VM instance (like a skeleton VM) on the destination host and memory is allocated for this VM Step2 Memory contents of the migrating VM are copied over to the destination host. This memory is divided in to pages of 4K in size. There will be dirty bitmap created for these memory pages. Source host monitors these memory pages for any changes as the VM is still running. These new modified pages will be marked dirty again in the bitmap. Hyper-v iterates through these modified pages again and moves them to the destination host. However, this has to stop at some time; otherwise we will be in a loop. The number of such iterations is limited to 10 Step3 Put VM in to a saved state; All remaining modified pages are transferred; registers and device state is copied to the destination host. This is where network bandwidth plays a critical role. Hence, 1Gig ethernet is recommended. If the VM was under heavy load when live migration was initiated, this step might take longer because there will be more number of modified pages. Now, the VM on destination host is up-to-date; The goal of this step is to complete in less than 20ms. Otherwise, there will be TCP connection timeout and clients connected the VM may see the disruption of service Step4 Transfer storage ownership to the destination host Step5 Resume the VM on the destination host

R2: Cluster Shared Volumes Live migration requires shared storage and cluster shared volumes (CSV) enable this You can enable this feature from failover cluster manager console CSV provides a single consistent file name space Files have the same name and path when viewed from any node in the cluster CSV volumes are exposed as directories and subdirectories under the “ClusterStorage” root directory C:\ClusterStorage\Volume1\<root> C:\ClusterStorage\Volume2\<root> C:\ClusterStorage\Volume3\<root> Failover Clustering has implemented a “shared nothing” storage model for the last decade Each Disk is owned by a single node at any one time, and only that node can perform I/O to it

Concurrent access to a single file system R2: CSV Disk5 Single Volume VHD SAN Concurrent access to a single file system All physical hosts have access to the same shared physical LUN. Each VM stores its VHD on the shared storage and hence eliminating the need for LUN ownership changes

Virtual Machine Switch R2: VMQ Parent Partition VM1 VM2 Ethernet VM BUS TCP/IP VM NIC 1 VM NIC 2 Virtual Machine Switch NIC Miniport Driver Routing VLAN Filtering Data Copy Port 1 Port 2 Receive path VM Switch has to parse incoming packets and route them to a proper VM based on MAC address VLAN ID Copying data from parent partition address space to the child partition Then interrupt the guest to take the data and guest will copy the data to its own address space Too many copy operations Send Path Copying data from child partition address space to the parent partition address space MAC address lookup and VLAN ID filtering Parent/child context switch overhead Simulating task offload in software for VM to VM traffic Extra copy for VM to VM traffic Virtual Network data path without VMQ

Virtual Machine Switch R2: VMQ Parent Partition VM1 VM2 Ethernet VM BUS TCP/IP VM NIC 1 VM NIC 2 Virtual Machine Switch Miniport Driver Switch/Routing unit Q1 Default Queue Q2 Routing VLAN filtering Data Copy Port 1 Port 2 NIC Need a separate NIC that support VMDq. Something like Intel Quad Port Intel –VT 1Gig adapter or Dual Port 10Gig Intel-VT adapter Enhances the overall network throughput and reduces CPU cycles spent in handling VM network traffic Virtual Network data path with VMQ

R2: Core Parking Without core parking, When the system is working at even 10-20% of overall capacity, all processor cores are active. They may be using DBS or PowerNow to reduce the frequency of the core but that does not result in huge power savings. Core parking consolidates processing onto the fewest number of possible processor cores, and suspends inactive processor cores hence resulting in better power savings

R2: Native VHD support Natively supports creating / managing VHDs Native support all VHD types Fixed Dynamic Differencing Diskpart.exe or diskmgmt.msc can be used to create VHDs No CIMv2 WMI interfaces; you must have Hyper-v role enabled for using WMI to create VHDs For creating a differencing disk you need to use diskpart.exe only

R2: Native VHD boot Supports booting from a VHD “without” any hypervisor software Can be used to create multi-boot configuration without “really” installing OS Improved WDS to enable native VHD boot deployment Benefits Single image Same image format for WDS, unattended and VM deployments Inline with single file format efforts within MS

References Beta build download - http://www.microsoft.com/downloads/details.aspx?FamilyId=85CFE4C9-34DE-477C-B5CA-75EDAE3D57C5&displaylang=en Beta reviewers guide - http://download.microsoft.com/download/F/2/1/F2146213-4AC0-4C50-B69A-12428FF0B077/Reviewers_Guide_Beta_update.doc