What is your Virtual Function?

XenServer

VDI-in-a-Box is an interesting desktop virtualisation solution from Citrix because it utilises local storage; its aim is to simplify and reduce the cost of entry to desktop virtualisation for small and medium businesses. The main premise is that each piece of hardware acts as a single entity in a grid, as capacity is reached additional servers can be added, enabling the solution to be scaled out block-by-block.

When sizing VDI-in-a-Box there are four main considerations; disk space, disk speed, RAM and CPU. I will look at each and discuss its potential impact. All calculations come from Citrix eDocs guide; VDI-in-a-Box > VDI-in-a-Box 5.0.x > System Requirements for VDI-in-a-Box 5.0.2 or are referenced via link.

Disk Space

Calculating disk space requirements will depend upon your hypervisor and the number of images you intend to utilise. In the calculations below I have assumed that XenServer 6.0 with Thin Provisioning is utilised and that 2 images will be required for 2 desktop types, power users and normal users.

Fixed items will be the storage required for the hypervisor and the vdiMGR appliance, plus Citrix recommends reserving an amount for swap and transient activity. In the Dell and Kaviza reference architecture they recommend 100 GB. Therefore, in this instance, fixed storage will be:

8 GB for the hypervisor + 74 GB for the vdiMGR appliance + 100 GB for swap and transient activity

=182 GB

For the desktops images, templates and virtual desktops, we will assume we are using non-persistent desktops, that we require 2 images and that the base image size is 20 GB for both desktop types. VDI-in-a-Box uses 2 times the image size, to maintain multiple images, and the cloning technology uses 15% of the original size of the desktop image for each desktop created. Therefore if we require 100 desktops the desktop storage requirement per host will be:

I recommend adding addition space for growth; in this instance I will assume 30%. Therefore total disk capacity requirements will be:

Fixed items + desktops + growth

= (182 GB + 380 GB) + 30%

= 562 GB + 167 GB

= 729 GB

Disk Speed

Disk speed is all about IOPS, understanding desktop IOPS is an art in itself. There are a number of main areas of consideration; boot IOPS, login IOPS, average use or normal operation IOPS, application launch IOPS and log off IOPS for the user type (e.g. normal or power user). A good guide to IOPS considerations and measurements has been written by Jim Moyle titled “Windows 7 IOPS for VDI a Deep Dive 1.0”

In my example IOPS numbers should be seen as a guide only to assist you in determining the disk speed required for your deployment. The fastest disk is not always the most economical, therefore once you have determined the IOPS required it is worth looking at different options for your hardware based on capacity versus unit cost.

In this guide I have referenced the Citrix blog article “Finding a Better Way to Estimate IOPS for VDI”. This is by no means a definitive guide however the section I have utilised “Calculating Workload IOPS” has a useful sub-section on user definitions and a recommended “ballpark guesstimates” figure for IOPS per workload. By utilising these numbers I have been able to simplify my calculations and focus just on this number and not the boot and login numbers. The user definitions are listed below:

Light user: ~6 IOPS per concurrent user. This user is working in a single application and is not browsing the web.

Normal user: ~10 IOPS per concurrent user. This user is probably working in a few applications with minimal web browsing.

Power user: ~25 IOPS per concurrent user. This user usually runs multiple applications concurrently and spends considerable time browsing the web.

Heavy user: ~ 50 IOPS per concurrent user. This user is busy doing tasks that have high I/O requirements like compiling code or working with images or video.

Therefore in this example if we require 100 desktops, made up of 25 power users and 75 normal users our “guesstimate number” for IOPS will be:

(# of power users * 25 IOPS) + (# of normal users * 10 IOPS)

= (25 * 25) + (75 * 10)

= 625 + 750

= 1375 IOPS

Please note: to gauge a true reflection of required IOPS I would suggest monitoring the current usage patterns and workloads in your environment. To bring the peak IOPS requirement down consider the start-up and login patterns and how these can be managed; e.g. allowing for a longer boot time and starting the boot process overnight or early in the day or by only allowing users to log off desktop not reboot and decide what you want to happen to desktops when a user does log off.

RAM

RAM requirements are an easier calculation to make however we still have to make a number of assumptions. Total RAM required will be the RAM required for the hypervisor, plus the RAM required for the vdiMGR appliance, plus overhead, plus the RAM required for the virtual desktops.

Citrix recommends at least 1.5 GB for Windows 7 and at least 0.5 GB for XP, with 1 GB for the hypervisor, 1 GB for the vdiMGR appliance and a 10% overhead.

I have made the assumption that all my desktops are Windows 7 and that a normal user requires 1.5 GB RAM and a power user 2 GB RAM. Therefore in this example the total RAM required is:

CPU is similar in terms of RAM requirement in that we need CPU for the hypervisor, the vdiMGR appliance, overhead and virtual desktops. The amount of CPU required per user type will vary, in my example I will only be assigning 1 vCPU per desktop however I will make the assumption that I will get less power users per core. Definitions vary; Citrix eDocs states 10 for task workers, 8 for knowledge workers, and 6 desktops per core for heavy users and the Dell reference architecture states 5 for basic users and 6 desktops per core for standard users.

In my example I have picked an average and will assign 8 desktop per core for normal users and 6 desktops per core for power users. Therefore the total CPU requirement is:

In my example I have 100 users in total of which 25 are classed power users and 75 normal users.

Each user will be supplied with a Windows 7 virtual desktop with 1vCPU, however normal users will receive 1.5 GB RAM and power users 2 GB RAM.

In total I will require:

792 GB of disk space

1375 IOPS

181 GB RAM

17 CPU cores

Choosing your Hardware Configuration

Considerations

There are a number of considerations we need to take into account when selecting hardware.

The first we need to discuss is availability. Server class hardware is great however I do not like the idea of 100 desktops not being available, therefore for my example I am going to suggest an N+1 strategy. This will always depend upon risk vs. expenditure and ultimately needs to be a business decision.

Secondly we need to think about type of hardware, disk type speeds and RAID configuration. As all resources are on a single appliance and we need IOPS and disk space, in most instances blade configurations will be out of the question, as we will only have two disks. Therefore we are often looking at a 2 – 4 U server.

In regards to RAID configuration, RAID 0 will give us maximum disk capacity and IOPS availability but may make us nervous about availability, leaving RAID 1 + 0 as the option that gives us disk space and availability without too much penalty.

Finally we need to consider disk seep as IOPS availability is important. Citrix’s VDI-in-a-Box sizing guide states the following disk speeds

In my calculations I have selected a middle ground and used the following:

SSD = 6,000 IOPS

15K = 175 IOPS

10K = 125 IOPS

Hardware Options

The two figures that stand out for me in total resources required are IOPS and RAM. See example below for a basic server configuration (Host Specifications):

In the example above, Table 1, a server with 16 cores, 96 GB of RAM and 8 x 15K SAS spindles in a RAID 1 + 0 configuration can support 25 power users and 56 normal users based on my previous calculations and assumptions. And as you can see it is the IOPS that restricts the number of power users and RAM that restricts the number of normal users.

In Table 2 below if we increase the RAM to 128 GB the number of power user desktops is still limited by IOPS however the number of normal user desktops is now also limited by IOPS. Therefore if we had purchased a server in this configuration we would have been wasting money on RAM. To take advantage of this amount of RAM we would either need to change the disk type or increase the number of spindles.

At no point in the two hardware examples has CPU cores or disk capacity been an issue.

Getting the hardware right is important and your number of servers will depend upon your appetite for risk plus your understanding of your environment.

Analysing your environment before you start to gauge IOPS is an important step. The numbers here will help but can only be used as a guide. Partners familiar with VDI-in-a-Box will have a good understanding of resources required and may be able to speed up this process based on their history of work.

Finally if you have completed some analysis just using some list price numbers on hardware you’ll see that by understanding your limit points, you can make sure you get the best return on hardware investment and reduce the overall cost per desktop.

I use a Vyatta virtual router in my home lab to segregate my test networks from the home one. I first used the virtual appliance over a year ago and its be faultless ever since. I can’t claim to use more that 1% of its functionality as a) networking is not my thing and b) it does what I need and I’ve left my investigation at that. So if you want to spin one up on XenServer 6.0 here is what you need to do.

Download the latest iso from Vyatta. You have to enter your details to do this and if you are not paying a subscription then some features, such as the web GUI will not be available to you. As a tes lab router however you’ll be able to do everything you need.

Create a new VM on XenServer 6.0, select Other, and assign a disk (at least 1GB – I use 20GB) and 512MB of RAM (I use 1GB). In regards to network interfaces you will need to work out in advance where you want your device to site in your network. I have created two networks on my XenServer host, Network 0 and Testlab and both are bound to the single NIC I use. My new VM therefore has two network interfaces one on Network 0 and one on Testlab.

Make sure the iso you have down loaded is in the new VM DVD drive and start up the machine.

The iso is known as the live iso and will not install by default. Login in using the default credentials (username= vyatta , password = vyatta) and run the following commands:

install-system
Select all defaults until you get to the following section, where you change the option to yes “Would you like to set up config files to prepare for the conversion to PV domU? [No]: ” yes

Following the install I run the commit and save commands then shutdown .

At reboot you will now want to install the Xen tools. To do this make sure the xen tools iso is in the VM DVD Drive, login in and and execute the following commands:

Configure

sudo mount /dev/cdrom /mnt

ls /mnt/Linux

sudo dpkg -i /mnt/Linux/xe-guest-utilities_6.0.0-743_i386.deb

sudo umount /dev/cdrm /mnt

commit

save

shutdown

Restart the VM and login to the console. you can now add IP addresses to the interfaces and a static route so your test lab machines can access you home router and out to the Internet. I have also set a static route on my home router so it can get back to the testlab VLAN. I have listed examples of commands that you may find useful below:

Last Tweets

I was lucky enough to join the Australian Institute of Company Directors swim team for the #PorttoPub swim in Perth Western Australia. The race was called off at the three hour mark due to the tough conditions. However it proved again to me that a good t…https://t.co/AMf3zGNVEx,7 hours ago