Cisco vWAAS Configuration Guide (for WAAS 6.4.1x)

System Infrastructure Requirements

Your WAAS system must have the following to deploy vWAAS on Hyper-V:

• Microsoft Hyper-V Hypervisor—Hypervisor enables multiple operating systems to run on a single host. vWAAS runs as a guest on any host running Hyper-V 2008 R2 or greater.
• Hyper-V Virtual Switch—The Hyper-V Virtual Switch is a software-based Layer 2 switch that connects virtual machines to both virtual networks and the physical network. It provides policy enforcement for security, isolation, and service levels, and includes features for tenant isolation, traffic shaping, simplified troubleshooting, and protection against malicious virtual machines.
  
  Hyper-V Virtual Switch is available in Hyper-V Manager when you install the Hyper-V server role.

Hardware Virtualization Requirements

This section describes vWAAS on Hyper-V hardware virtualization requirements for CPU, disk, CD-ROM, and flash.

• CPU—vWAAS on Hyper-V supports 2, 4, and 8 CPU configurations. vWAAS on Hyper-V does require a minimum CPU limit.

Note vWAAS VM (Virtual Machine) with different CPU configurations works, but is not recommended.

• Disk sizes for vWAAS on Hyper-V— Disk sizes for vWAAS on Hyper-V are the same as those for ESXi, for each model. For more information on disk sizes for WAAS versions up to Version 6.x, see section ESXi Server Datastore Memory and Disk Space for vWAAS and vCM Models in Chapter 4, “Cisco vWAAS on VMware ESXi” .
• CD-ROM—vWAAS on Hyper-V supports standard ISO image file for its CD-ROM device.
• Flash—Unlike physical WAAS devices, vWAAS on Hyper-V does not have access to a separate flash device. Instead, vWAAS flash is installed on the first hard disk, and also uses this first disk for booting. A separate larger disk hosts the DRE/CIFS caches, etc. Other flash functionalities are supported as in ESXi.

OVA Package for vWAAS on Hyper-v for WAAS Version 5.x to 6.2.x

For vWAAS on Microsoft Hyper-V, for WAAS Version 5.x through 6.2.x, Cisco provides an OVA or NPE OVA package for each vWAAS connection profile (examples shown in Table 5-4) and for each vCM connection profile (examples shown in Table 5-5).

The Cisco OVA package for vWAAS on Microsoft Hyper-V contains the following:

• SCVMM template file
• WAAS image.iso file
• Virtual Hard Disk (VHD) file for flash
• PowerShell deployment script for SCVMM
• PowerShell deployment script for standalone hosts

Note For a listing of hypervisor OVA, zip, and tar.gz files for vWAAS, see the Cisco Wide Area Application Services (WAAS) Download Software Page and select the WAAS software version used with your vWAAS instance.

Table 5-4 OVA Package Format Examples for vWAAS on Hyper-V for WAAS Version 5.x to 6.2.x

Table 5-5 Cisco OVA Package Formats for vCM for WAAS Version 5.x to 6.2.x

Unified OVA Package for vWAAS on Hyper-V for WAAS Version 6.4.1 and Later

For vWAAS on Microsoft Hyper-V for WAAS Version 6.4.1 and later, Cisco provides a single, unified OVA for NPE and non-NPE version of the WAAS image for all the vWAAS models for that hypervisor.

Each unified OVA package is a pre-configured virtual machine image that is ready to run on a particular hypervisor. The launch script for each unified OVA package file provides the model and other required parameters to launch vWAAS with WAAS in the required configuration.

Here are examples of the unified OVA and NPE OVA package file filenames for Microsoft Hyper-V:

• OVA—Cisco-HyperV-vWAAS-Unified-6.4.1-b-33.zip
• NPE OVA—Cisco-HyperV-vWAAS-Unified-6.4.1-b-33-npe.zip

The unified OVA package for Microsoft Hyper-V contains the following files.

• SCVMM template file
• WAAS image iso
• Virtual hard disk file for Flash
• PowerShell deployment script for SCVMM and a set of template.xml files
• PowerShell deployment script for Standalone Hosts and a set of template.xml files

Installing vWAAS on Hyper-V for vWAAS on WAAS Version 5.x to 6.2.x

vWAAS on Hyper-V is installed using the Microsoft Virtual Machine Manager (VMM), with the Virtual Hard Disk (VHD) file. During installation, there is an option to import pre-configured and pre-installed vWAAS images to Hyper-V. After you have completed installation, complete the activation and registration process with the procedures described in Activating and Registering vWAAS on Hyper-V.

This section contains the following topic:

• Installing vWAAS on Hyper-V with a VHD Template

Installing vWAAS on Hyper-V with a VHD Template

There are seven VHD templates available for vWAAS, and four VHD templates available for vCM.

You can import a pre-configured, model-based VHD file for your deployment. For more information on installing Hyper-V with a VHD template, contact your Cisco account representative.

To install vWAAS on Hyper-V with a VHD template, follow these steps:

Step 1 Download the vWAAS package to the computer where the SCVMM2012 or the 2012 R2 console is installed.

Step 2 Unzip the vWAAS package.

Step 3 Login to the SCVMM console.

Step 4 Launch the PowerShell window that is displayed in the SCVMM.

Step 5 Navigate to the PowerShell script in the uncompressed vWAAS package:
“.\Cisco-vWAAS-model-name-6.0.0-ISO\Cisco-vWAAS-model-name-6.0.0-ISO”

Step 6 Run the PowerShell script: “deploy-vwaas-model-name”

Step 7 Follow the procedure that is requested by the deployment script.

Step 8 If your deployment uses a vWAAS-12000 or vWAAS-50000 model, you must enter a maximum amount of memory in NUMA (Non-Uniform Memory Access) configuration of at least RAM size or higher, in MB, otherwise the device will not be able to boot up.

Note Entering the maximum memory amounts as shown in Step 9 should be completed only after you have deployed vWAAS in Hyper-V (as shown in Step 1 through Step 7).

Step 9 To enter the maximum amount of memory, follow these steps:

a. From the SC VMM console, navigate to Hardware > Processor > NUMA.

b. The NUMA Configuration screen is displayed.

c. At the Maximum amount of memory (MB) field, enter an amount, in MB:

• For vWAAS-12000, enter an amount of at least 12288 MB.
• For vWAAS-50000, enter an amount of at least 49152 MB.

Installing vWAAS on Hyper-V for WAAS Version 6.4.1 and Later

To deploy Microsoft Hyper-V for vWAAS for WAAS 6.4.1 and later, follow these steps:

Step 1 From the Cisco WAAS Installer for Hyper-V, as shown below, enter the number of your vWAAS or vCM model:

Step 2 The automated Hyper-V package generation copies all the vWAAS model template XML files in the zip file. Based on your input, the corresponding XML template is registered and used for the specified vWAAS model deployment.

About Traffic Interception for vWAAS on Hyper-V

When vWAAS is deployed in Hyper-V hosts, the WAE device is replaced by the Hyper-V host. No change is required in the WAAS traffic interception mechanism in the switches or routers. The WCCP protocol also works like the vWAAS VMware ESXi deployment in the vWAAS Hyper-V deployment.

vWAAS on Hyper-V provides the same WAN acceleration functionality provided by the physical WAN acceleration WAE device. You can also deploy multiple vWAAS in one or more Hyper-V hosts to form a WAAS farm in either the Edge or the Core.

WCCP Interception

WCCP interception, WCCP GRE or WCCP L2, is supported for all vWAAS on Hyper-V deployments.

To select WCCP as the interception method for a WAE, follow these overview steps. For a full description of each step, see the Cisco Wide Area Application Services Configuration Guide.

Note Before you do the following procedure, you should have already configured your router for basic WCCP, as described in the Cisco Wide Area Application Services Configuration Guide.

Step 1 From the WAAS Central Manager menu, choose Devices > device-name.

Step 2 Choose Configure > Interception > Interception Configuration. The Interception Configuration window appears.

Interception Method Settings area

Step 3 From the Interception Method drop-down list, choose WCCP to enable the WCCP interception on the vWAAS device.

WCCP Settings area

Step 4 To enable WCCP on the device, check the Enable WCCP Service check box.

Step 5 With WCCP selected, the Service Type field displays TCP Promiscuous.

Step 6 In the Service ID1 field, specify the first service ID of the WCCP service pair, with an ID number of 1 to 99. After you submit, the Service ID2 field is filled in with the second service ID of the pair, which is one greater than Service ID1, with an ID number of 2 to 100.

Step 7 To use the default gateway of the WAE as the router to associate with the WCCP TCP promiscuous service, check the Use Default Gateway as WCCP Router check box.

If you leave this box unchecked, you can use the WCCP Routers field to specify a list of one or more routers by their IP addresses, separated by spaces.

WCCP Assignment Settings for Load Balancing area

Step 8 (Optional) From the Assignment Method drop-down list, choose the type of WAE load-balancing assignment method to use (Mask or Hash).

• Mask assignment method selected—To use a custom mask, enter a value for the source ID mask in the Source IP Mask field. The range, in hexadecimal, is 00000000–FE000000. The default is F00. Enter a value for the destination IP mask in the Destination IP Mask field. The range, in hexadecimal, is 0000000–FE000000. The default is 0.
• Hash assignment method selected—To specify the hash assignment method for the source IP address, check Hash on Source IP: either Service ID1 or Service ID2. After you check a source IP, the complementary destinantion IP is automatically selected, Hash on Destination IP: check box either Service ID2 or Service ID1.

WCCP Redirect and Egress Settings area

Step 9 From the Redirect Method drop-down list, choose WCCP GRE or WCCP L2.

Step 10 From the Egress Method drop-down list, choose L2 or IP Forwarding.

Advanced WCCP Settings area

Step 11 Check the Enable Flow Protection check box to keep the TCP flow intact and to avoid overwhelming the device when it comes up or is reassigned new traffic. For more information on flow redirection, see the Information about WCCP Flow Redirection on WAEs” section of the Cisco Wide Area Application Services Configuration Guide.

Step 12 In the Flow Protection Timeout field, specify the amount of time (in seconds) that flow protection should be enabled. The default is 0, which means flow protection stays enabled with no timeout.

Step 13 In the Shutdown Delay field, enter a maximum amount of time (in seconds) that the chosen device waits to perform a clean shutdown of WCCP. The range is 0 to 86400 seconds. The default is 120 seconds.

Step 14 From the Failure Detection Timeout drop-down list, choose a failure detection timeout value: 30, 15, or 9 seconds. The default is 30 seconds. The failure detection timeout determines the length of time for the router to detect a WAE failure.

Step 15 In the Weight field, specify the weight to be used for load balancing. The weight value range is 0 to 10000.

• If the total of all the weight values of the WAEs in a service group is less than or equal to 100, the weight value represents a literal percentage of the total load redirected to the device for load-balancing purposes.
• If the total of all the weight values of the WAEs in a service group is between 101 and 10000, the weight value is treated as a fraction of the total weight of all the active WAEs in the service group.

Step 16 In the Password field, specify the password to be used for secure traffic between the WAEs within a cluster and the router for a specified service. Be sure to enable all other WAEs and routers within the cluster with the same password. Passwords must not exceed eight characters in length. Do not use the following characters: space, backwards single quote (‘), double quote (“”), pipe (|), or question mark (?).

Re-enter the password in the Confirm Password field.

Step 17 Click Submit to save the settings.

AppNav Controller Interception

AppNav interception is supported for all vWAAS on Hyper-V deployments, and works as in the current ESXi vWAAS models.

AppNav interception enables a vWAAS node to receive traffic optimization from an AppNav controller (ANC) in an AppNav deployment. If vWAAS VMs are part of an AppNav deployment and are configured as WAAS nodes (WNs) in an AppNav cluster, you must configure the AppNav-controller interception method. These WNs receive traffic only from the ANCs; they do not receive traffic directly from routers.

To select AppNav as the interception method, follow these steps:

Step 1 From the WAAS Central Manager menu, choose Devices > device-name.

Step 2 Choose Configure > Interception > Interception Configuration. The Interception Configuration window appears.

Step 3 From the Interception Method drop-down list, choose appnav-controller to enable appnav-controller interception on hte vWAAS device.

Step 4 Click Submit.

vWAAS Deployments, UCS-E Upgrades, and Windows Server Updates

Caution Multiple deployments of vWAAS on the same Hyper-V host in parallel may cause unexpected results, due to availability of free space when creating VHDs. We recommend that you do not deploy multiple vWAAS on Hyper-V in parallel, unless you have verified that you have enough free disk space required for the respective vWAAS models.

---

To ensure reliable throughput with the following configuration—vWAAS on Windows Server 2012 R2 Hyper-V in Cisco UCS-E Series 160S-M3—we recommend that you do the following:

• Upgrade to the latest UCS-E firmware (Version 3.1.2), available on the Cisco Download Software Page for UCS E-Series Software, UCS E160S M3 Software.
• Verify that you have installed the critical Windows Server updates, available on the Microsoft Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 Update Rollup page. You can also obtain the standalone update package through the Microsoft Download Center by searching for KB2887595.

Configuring NTP Settings for vWAAS on Hyper-V

The Network Time Protocol (NTP) allows synchronization of time and date settings for the different geographical locations of the devices in your WAAS network, which is important for proper system operation and monitoring. When you configure NTP on vWAAS with Hyper-V, the time gets updated from the NTP server.

Caution To ensure that the vWAAS on Hyper-V system clock remains in synchronization with the system clocks of other WAAS devices, especially after a reload of vWAAS on Hyper-V, you must uncheck the Time synchronization option. This option must be unchecked in the system that you are using for vWAAS on Hyper-V: System Center Virtual Machine Manager (SC VMM) or the Hyper-V Manager.

---

To uncheck the Time Synchronization option for NTP configuration, follow these steps:

Step 1 Uncheck the Time Synchronization option in either the SC VMM or the Hyper-V Manager:

From the SC VMM:

a. Select vWAAS VM.

b. Choose Settings > Management > Integration Services.

c. Verify that the Time synchronization option is unchecked.

d. Click OK.

From the Hyper-V Manager:

a. Select vWAAS VM.

b. Choose Properties > Hardware Configuration > Advanced > Integration Services.

c. Verify that the Time synchronization option is unchecked.

d. Click OK.

Hyper-V High Availability Features

vWAAS on Hyper-V provides multiple high availability solutions, including:

• Live Migration
• NIC Teaming

Live Migration

Hyper-V live migration moves running VMs with no impact on VM availability to the user. It does this by pre-copying the memory of the migrating VM to the destination physical host. The administrator, or the script, that initiates the live migration controls which computer is the destination for the live migration. There is no need for special configuration for the guest operating system, as that is not affected by the live migration.

There are three methods you can use to initiate a live migration:

• Failover Cluster console
• Virtual Machine Manager Administration console (if Virtual Machine Manager is managing physical hosts that are configured to support live migration)
• A PowerShell or WMI script

The following is a workflow for initiating and completing a live migration:

• Create a connection between hosts—The source physical host creates a TCP connection with the destination physical host, which is used to transfer the VM configuration data to the destination physical host. A skeleton VM is set up on the destination physical host, and memory is allocated to the destination VM.
• Copy the working set to the destination host—The memory assigned to the migrating VM, called the working set, is copied to the destination physical host. This memory is referred to as the working set of the migrating VM. A page of memory is 4 kB in size.
• Mark modified memory pages—The utilized pages within the working set are copied to the destination Hyper-V physical host. In addition to copying the working set to the destination physical host, Hyper-V on the source physical host monitors the pages in the working set. As the migrating VM modified the memory pages during live migration, Hyper-V tracks and marks them as modified.
• Copy modified memory pages—During live migration, Hyper-V iterates the memory copy process several times. Each time, a smaller number of modified pages need to be copies to the destination physical host. A final memory copy process copies the remaining modified memory pages to the destination physical host.
  
  The source physical host transfers the register and device state of the VM to the destination physical host. During this stage of live migration, the network bandwidth available between the source and physical host is critical to the speed of the migration. Therefore, 1 Gigabit Ethernet is recommended.

Note The number of pages to be transferred in this stage is dictated by how actively the VM is accessing and modifying memory pages. More modified pages means a longer VM migration time, to allow for all memory pages to be transferred to the destination physical host.

• Complete the live migration—After the modified memory pages have been completely copied to the destination physical host, the destination physical host has an up-to-date working set of the migrated VM: the working set for the migrated VM is present on the destination physical host in the exact state it was in when the migrated VM began the live migration process.

Note You can cancel the live migration process at any point before this phase of the process.

• Transfer control of the migrated VM memory and storage—Control of storage associated with the migrated VM, such as VHD files or pass-through disks, and control of memory (working set) are transferred to the destination physical host.
• Bring migrated VM online—The migrated VM is brought online on the destination physical host.

NIC Teaming

The failure of an individual Hyper-V port or virtual network adapter can cause a loss of connectivity for a virtual machine. To prevent this, multiple virtual network adapter are used in a NIC (Network Interface Card) teaming configuration, which provides both high availability and load balancing across multiple physical network interfaces. NIC teaming is also known as network adapter teaming technology and LBFO (Load Balancing Failover).

For vWAAS on Hyper-V, NIC teaming, in Windows Server 2012, enables a virtual machine to have virtual network adapters that are connected to more than one virtual switch, and will still have connectivity even if the network adapter under that virtual switch is disconnected. NIC teaming on Windows Server 2012 supports up to 32 network adapters in a team.

With NIC teaming, you can set up two virtual switches, each connected to its own SR-IOV-capable network adapter. NIC teaming then works in one of two ways:

• Each virtual machine can install a virtual function from one or both SR-IOV network adapters. If a adapter disconnection occurs, the traffic can fail over from the primary virtual function to the backup virtual function without losing connectivity.
• Each virtual machine can have a virtual function from one network adapter and a non-virtual functional interface to the other switch. If the network adapter associated with the virtual function becomes disconnected, the traffic can fail over to the other switch without losing connectivity.