Hyper-V Dynamic Memory as a tool for understanding your Applications

In case you missed it, MSFT is making a bit of noise about the new Dynamic Memory feature that is coming in the SP1 release for Server 2008 R2 / Hyper-V Server R2.

My angle on this is a bit different than most.

The way that Dynamic Memory has been implemented by the MSFT folks is rather interesting.  It is memory ballooning under the hood – but it is hooked into the operating system of the VM in a way that only Microsoft could (as it owns the OS in this case).

What I find most interesting is the way that the Dynamic Memory feature responds to the needs of the application that is running in the virtual machine.

If the application begins needing additional RAM, then Dynamic Memory attempts to give it some, once the application frees up the RAM, then Dynamic Memory takes it back away.

This has the net effect that your machine is always running in an optimal ‘sweet spot’ as far as RAM is concerned.

The most interesting part is that you can perform actions against your VM and you can see how Dynamic Memory responds and in turn understand how your application demands additional RAM.  You can load it to a certain level and get a really good baseline.

Considering that managing a virtual environment is still a bit of a black art this is highly useful in really understanding the demands of your workload in a way that means something.  This directly correlates to a resource – RAM of all things – a very finite resource in most cases.

The end result is that you get a really good indicator of the range of RAM that your workload really needs.

I have said for years that most folks give their servers too much RAM (especially VMs) – and this is a great tool to prove it and to give a really excellent indication of the true RAM utilization of your workload.

Yes, you have to observe the numbers (in the UI or through polling WMI) but I think the return that you get for your time spent doing that is well worth it.

Migrating a XenDesktop environment from VMware to XenServer

I have had a recent need to migrate a working XenDesktop environment from VMware over to XenServer.

Following are some guidelines that can be used by most anyone who is in this situation.

The (fully) Virtual Environment:

• XenDesktop 4 Desktop Delivery Controller (Windows 2003 R2, x64, 2vCPU, 4GB RAM, 1 NIC)
• Licensing Server (Windows 2008, x86, 1 vCPU, 2GB RAM, 1 NIC)
• Web Interface server (Windows 2008 R2, 2 vCPU, 4GB RAM, 1 NIC)
• Provisioning Server (Windows 2008, x64, 4 vCPU, 16GB RAM, 1 NIC)
• Master VM (the VM where the desktop image is installed, Windows 1, 1 vCPU, 1GB RAM, 1 NIC)
• PvS Template (the VM template that is cloned to create new Desktop virtual machines)
• Desktop VM (the actual virtual machines that the Provisioning Server image is streamed to and runs the users applications)

The Export:

1. Use vApp containers to export OVF packages as groups of machines
1. Organize the XenDesktop application tier machines into a vApp container named “Infrastructure”. This is so they can be exported as a group of machines in a single OVF package.
2. Power off the Infrastructure vApp (this can also be done individually by virtual machine).
3. Export the Infrastructure to an OVF package
1. Be sure to select the Infrastructure container and choose File, Export, Export OVF Template. Leave the option to export to an OVF (a folder of files) – this speeds up the process since there is no requirement for creating a single OVA file (which takes longer to export and import).
4. Export the Master VM
1. To keep the Master VM as uncluttered and clean as possible it is recommended to uninstall the VMware Tools prior to export.
5. Export the PvS VM Template
1. If for no reason other than documentation purposes because the OVF contains all of the settings of the original template. With XenServer it is recommended to use an included base template for optimal configuration.
6. Export the virtual desktops - an additional export consideration
1. Before exporting the currently deployed virtual desktops there are two options to think about. Do you export your existing virtual desktops (this is highly useful if they have local cache disks on the hypervisor) or do you not export your existing virtual desktops. In both cases you need to create new desktop groups on the Desktop Delivery Controller.
2. If your Desktop VM images were derived from a template (for example: using the XenDesktop Setup Wizard) the deployed desktop virtual machines probably have dynamic MAC addresses assigned to the VMs.
1. The VMware OVF does not record the currently assigned MAC address if it is set to dynamic. This means that when imported these machines will be assigned new MAC addresses.
3. If Provisioning Server is used; the “auto add” feature can be implemented, to automatically add the Imported desktop VMs to Provisioning Server or the MAC addresses of each VM can be updated in the XXX configuration of Provisioning Server.
4. If you choose to not export the existing Desktop virtual machines you can create new Desktop groups using the PvS Template with the XenDesktop Setup Wizard on the XenServer environment.

In this example I elected not to export the virtual desktops. Primarily because they are pooled and there is little benefit in doing so.

The Import

1. Import the OVF packages into XenServer using the fix-up option
1. From XenCenter select a target XenServer, Resource Pool, or folder and launch the Appliance Import Wizard from the File menu.
2. Browse to the Infrastructure OVF package and begin the import. Be sure to use the “fix-up” option because these machines were built on ESX server.
2. Install XenTools into each VM in the environment
1. Before powering on each VM be sure to check that the original VM is powered off (or disconnected from the network). Otherwise there will be two of the same machine on the network at the same time.
2. Log into each VM and install the XenServer tools, reboot, and proceed to manually fix any network settings. Don’t forget the Master VM.

Application Configuration Update

1. Make any setting changes to the XenDesktop and Provisioning Server applications
1. If you didn’t already do so login to the XenDesktop console and disable the Desktop Groups specific to the VMware environment
2. The XenDesktop installation uses Fully Qualified Domain Names and therefore relies on DNS, so make sure that all of the machine names are resolving properly.
2. Double check all Provisioning Server Settings
1. If the IP address of the Provisioning Server VM has changed be sure to make that configuration change in the Server configuration of your Site.

Update the Desktops and Desktop Groups

1. Update the vDisk Image from the Master VM
1. Be sure to set the vDisk to read / write mode in its settings in Provisioning Server. Also, modify the machine configuration in Provisioning Server with the new MAC address of the Master VM.
2. A gotcha to be aware of: the PVS driver binds to the NIC driver of the machine when it is installed. Migrating the VM to XenServer and installing XenTools and uninstalling VMware tools all cause the NIC and / or driver in the VM to be changed and therefore breaks the PVS Image driver. To resolve this uninstall and re-install the PVS “Target Device” software on the Master VM.
3. Run XenConvert to update the vDisk with the latest working Master VM image.
4. Set the vDisk back to Standard Image mode.
2. Use the XenDesktop Setup Wizard to create new Desktop Groups
1. Create a new VM in your XenServer environment (using a XenServer template)
2. Convert this to a Template
3. Run the XenDesktop Setup Wizard to build out a new set of replacement desktop images.
3. Verify it is working
1. Now that all settings are in place; wait for the DDC to refresh the new desktop groups and to spin up virtual machines for the idle desktop pool.
2. Check the console of a few VMs to see that the PVS image is streaming properly and connect to a desktop.

The summary

With one practice run I would feel confident in understanding the process to do this with a production environment – I would probably handle it in stages – but I would know enough to be able to properly plan.

In Summary:

1. Use vApp containers to export OVF packages that contain groups of machines.
2. Import the OVF packages into XenServer and use the fix-up option.
3. Install XenTools into each VM in the environment.
4. Double check network settings (including DNS) of each infrastructure VM.
5. Make any modifications I needed in Provisioning Server settings for new VM MAC addresses and Server IP address changes.
6. Update the vDisk Image
1. Uninstall and re-install the PVS client due to the virtual NIC driver changing.
7. Re-create the desktop pools

The Video Companion

For the impatient among us I have outlined the basic steps and gotchas in the following video:  http://www.citrix.com/tv/#videos/2748