Storage normally becomes thebottleneck when hosting virtualdesktops. For a successfulimplementation of VDIenvironments, the storage mustbe fast and highly available. TheVirtual Desktop Server 2.0 fromDataCore Software solves allthese associated problemsthrough adaptive caching andefficient use of disks or fasterSSD flash storage. The DataCoresolution consists of a storagevirtualization engine, whichimplements snapshot and cloningfeatures during operation to makea large number of desktopsavailable in a shorter time,without requiring a lot of storagein the process. In this way notonly can faster SSD flash storagebe integrated efficiently, but thinprovisioning features also ensurethe best possible capacityutilisation.

ArchitectureThe VDS consists of varioussoftware components, which aredeployed on Windows serversystems together with the Hyper­V hypervisor from Microsoft.These software componentsinclude the underlying storagevirtualization engine and the"DataCore VDS Console", agraphical user interface thatprovides users with variouswizards for creating, maintaining

and removing virtual desktops(VDIs) to speed up desktopprovisioning and deployment.The console is also able to collectdata, for example by monitoringimportant system resources, toensure high performance of theentire installation. In addition,there is the VDS Web Portal, atemplate for a website, whichallows access to the VDIs via theweb, as well as variousPowerShell scripts. The newfeatures in this version includefull integration with WindowsServer 2012, new templates,single sign­on access and ActiveDirectory support. Furthermore,the product can also be connectedinto Microsoft VDIenvironments, if required. In thislatter case the use of theDataCore Web Portal issuperfluous. As regards systemrequirements, VDS runs onWindows Server 2008 R2 withService Pack 1 and the latestupdates, as well as on WindowsServer 2012 Standard andDatacenter editions. It alsorequires the .NET Framework3.5.1. In terms of hardwarerequirements, the server should

provide adequate workingstorage as well as an Intel XeonCPU or the like. At the smallestset­up level the VDS manages 25virtual desktops; in this case thehardware must have a workingmemory of at least 32 GBytes.The virtualization system canhowever be scaled up to 200VDIs; the larger the environment,the more working memory mustbe logically available.

The testIn testing we installed the VDSon a standard x86 server with amulti­threading compatible dualcore CPU with a 3.3 GHz clockrate. An internal SATA hard diskwas used as a storage unit for theoperating system, and an SSDand a USB 3.0 hard disk forexternal storage. The workingmemory of the test device was 16GBytes. With this we did notmeet the minimum requirementsof the manufacturer, but as wenever deployed more than tenVDIs in our test, the memory wascompletely adequate. We usedWindows Server 2012 with theHyper­V role installed as theoperating system. Initially we

Product test: DataCore Virtual Desktop Server 2.0

Virtual desktops made easyDr. Götz Güttich

The Virtual Desktop Server 2.0 allows administrators to launch and maintain virtualdesktops with relatively little effort. These virtual desktops are stateful, which means

that they retain all the changes made by the users and are not reset back to defaultvalues after every restart. IAIT had a look at how the system works in practice.

1

tried with a German system, butthe VDS could not be deployedon it. Even installation of theEnglish language pack andchanging the system language toEnglish did not solve this issue.We therefore decided to set up anew English Server 2012. Afterthat we had no further problems.

Once the set­up was complete,we added two storage pools tothe system under test and thencreated a so­called "VDI source".This was a master VDI imagewhich was used as a source for

the VDI clones to be createdlater.

For the test we used a VDIsource based on Windows 7.After completing this activity wedeployed the VDS console tocreate and administer VDIs, andalso to delete them. Duringoperation we took a look at theprovisioning process of VDIs as

well and worked with the virtualdesktops. Finally, we used theVDS Web Portal to make ourVDIs available in the network.

InstallationTo install VDS on the server, itwas merely necessary to call upthe set­up file and to run theinstallation wizard. This wizardmainly asks for the installationpath and should therefore notovertax any administrator.

After completing the set­upwizard, two new icons are

available on the desktop. Oneserves to call up the"SANcentral" management tool,the other enables the start of the"VDS tools". We first called upSANcentral and started the serverservice. This step is onlynecessary once after installation.Should the server be restarted atsome stage for any reason, VDSboots itself. In fact, a reboot of

the server is only possible if theVDS service was manuallystopped previously viaSANcentral.

In a stand­alone configuration,such as our test environment, theinstallation was therefore alreadycomplete, but it is also possibleto perform a high­availabilityinstallation with a second HotStandby server. In this case, theresponsible IT staff person muststill create a service account thatis available on both servers, andrun the VDS CommunicationService under this account.

Initial start­upAfter the server had started wefirst changed our region. Regionsdeal with VDS configurationdomains. As standard, the set­uproutine selects the host name ofthe server as the region name. Wechanged this – also viaSANcentral – to a moremeaningful designation. We alsomodified the RAM settings dueto our somewhat limited workingmemory, so that the cache onlytook up 50 percent of theworking memory, instead of thestandard 66 percent, to ensurethat memory was still free foroperation of the VDIs. In the nextstage we created two storagepools with the SANmanager,which can be started fromSANcentral via the Tools menu.One of these pools was the"SourceImagePool", which wascreated using capacity from theSSD and which, duringoperation, was intended tocontain the image from which theVDIs are generated. To this wasadded the "ClonePool", whichrecorded the data that wasgenerated by the ongoing VDIoperation. After this wascompleted, we went on to

2

Start page of the VDS tools with the most important wizards

generate the source image, whichwas later used as the source forour clones.

For this, we created a new virtualmachine (VM) with the help ofHyperV Manager and installed32­bit Windows 7 Professionalunder this VM as a template forthe VDIs. We then installed theHyper­V integration services onthe VM and ran two scriptswhich DataCore had provided toprepare the virtual installation.For these scripts it is necessary tofirst set the execution policy tounlimited in the PowerShell(which must run withadministrator privileges)

The first script is called "VDIOptimization". This is aPowerShell script whichdeactivates superfluous servicesand tasks in Windows 7. It alsomodifies various system settingsto optimise the performance ofWindows for the VDIdeployment. According toDataCore, all essential Windowsfeatures are retained, while thescript simultaneously minimisesthe usage of I/O resources. Afterthe script had run we restartedthe VM.

The second script sets upWindows 7 so that the VDIclones generated from it havedistinct names at first start­upand – if required – join a domain.After the script has finished, theVM can be shut down and isready for use as a VDI source.Incidentally, the script must alsorun after each start of the sourcesystem – for instance followingchanges to the systemconfiguration. After the VM hadfinished shutting down, wedeleted it from our system usingHyper­V Manager and only kept

the VHDX file (that is, the virtualhard disk), which we moved to asafe location.

Working with the VDS ToolsNow we could set about puttingthe VDS environment itself intooperation. To do this, we calledup the "VDS Tools" and created a"Configuration Volume" with thefirst wizard offered. TheDataCore solution saves theconfiguration files of the VDIclones on this volume. It isnecessary to take the storagespace needed for theConfiguration Volume from adisk pool; we used our"ClonePool" for this. Also, thewizard wants to know the nameand size of the volume as well(we decided on 500 GBytes intesting).

After setting up theConfiguration Volume we createdour source VDI. If required,multiple different source VDIscan also be created for differentVDI configurations; VDSsupports parallel operation ofmultiple sources.

The "Create VDI Source Image"wizard of the VDS toolsgenerates a HyperV VM for useas a source VDI, which uses aDataCore Virtual Volume as itsboot drive. The source image caneither be created from a VHD file– as in our test – or from anexisting Virtual Volume.

Alternatively, it is also possibleto set up an empty VirtualVolume using the wizard and toinstall the operating system at alater stage. To create the image,the wizard needs the path to theVHD file that is to be used, andthe storage pool in which theimage lands; the source image

pool in our case. It also asks forthe name for the VDI image andwhether it should release unusedstorage space on the source harddisk after creating the image. Thelatter makes sense if you aretrying to avoid the storage poolbeing loaded with empty harddisk areas that nobody needs.

Finally, those responsible mustspecify how much workingmemory the VDI clone receives(in testing we allocated theclones 512 Mbytes of RAM), thevirtual network with which itcommunicates, and where theconfiguration files are to bestored (in our Config Volume).After the wizard had run, wefound a new VM in our Hyper­VManager. As we did not want towork with this – after all it onlyrepresented the source of ourVDIs – we deleted it again fromthe administration tool, so that itwould not be started accidentallyby any users, and additionallyused the SANmanager to unmapthe associated virtual drive. Thisensured that the source remainedundisturbed and was not subjectto manipulation attempts.

Creating the clonesAfter creation of the sourceimage all the preparatory stepswere complete, and we called upthe wizard for creating clones. Inthe first step we generated fiveclones. Later in the test welaunched up to ten VDIs inparallel. The wizard used tocreate the virtual desktops is alsoa component of the VDS tools,and first shows the number ofavailable licences and existinglicences, as well as the number ofVDIs still available. In addition,it wants to know how many VDIsit should create and which sourceimage to use. It also asks about

3

the storage pool for the clones(we used our clone pool here)and requests the base name forthe VDIs.

This base name is then expandedwith a number during operation,for example "VDI­1", "VDI­2"and so on. The staff responsiblecan also let the wizard know thestarting number, which is usefulif other VDIs of the same typeare already available in thesystem. To conclude, the wizardrequires details in terms of theworking memory, the storagespace of the configuration files(again, our ConfigFile Volume)and the virtual network to beused. Additionally, it can start thenewly created VDIs immediatelyafter creation, if required.

In operationAt first start­up, the clonesinitially carry out theprovisioning, which means thatthey change their host name fromthe name of the source image (inour test this was "VDI") to aunique name in the network (here"VDI­1" to "VDI­5"). They alsojoin a domain, where required.They then restart and are readyfor daily work. Provisioningmust only be carried out onceafter creation of the VDIs, andtook around 27 seconds in ourtest. The clones are consequentlyavailable very quickly, and thewizard ensures that the provisionof VDIs is extremely simple andcan therefore also be carried outby administrators who have noin­depth knowledge in thevirtualization area.

Apart from the wizards alreadymentioned, the VDS toolscomprise a large number ofadditional wizards for tasks thatarise during daily work. This

includes a wizard for deletingVDIs, which works analogouslyto the "Create VDI Clones"wizard, and a wizard whichreturns the selected VDIs to theoriginal state of the VDI source.In the process all user data is lost.Also of interest are the "VDI

Clone Tools". This is a collectionof tools which simplify thehandling of frequently recurringwork. The first tool is called"Start VDI Clones with Delay"and can be implemented to startup multiple VDIs with a timedelay

This makes sense when thenumber of clones concerned is solarge that the host cannot process

them all at the same time."Change VDI Clone Memory"provides the administrators withan option to adapt the workingmemory of one or more clones(they must however be switchedoff for this), and "Create VDIClone VMs from Existing Disks"

creates multiple clones from aconnected Virtual Volume."Create Standby VDI Clones"lastly allows the creation of VDIson the standby server in a high­availability configuration.

The last area of the VDI CloneTools deals with the monitoringof the running systems. "OpenWindows Performance Monitor"provides those responsible with

4

Wizard for generating a VDI source image

various tools for performancemonitoring. The monitoredparameters include the run timesof hypervisor and guests, thecache hits, the length of the diskqueue and much more.

Should bottlenecks occuranywhere, VDS will certainly not

leave administrators in the lurchwhen it comes totroubleshooting. Incidentally,performance monitoring runs viathe Microsoft PerformanceMonitor.

The last of the VDS Tools iscalled "Data Collection Logs".This allows MicrosoftPerformance Monitor Data

Collector sets to be installed andcontrolled.

These sets then recordpreconfigured performancecounters during operation that arerelevant for the performance ofthe VDI infrastructure.Administrators can then use the

logs later to find out, amongother things, how many VDIs thecurrent DataCore VDSconfiguration supports.

The web interfaceThere are two options forensuring that end users canaccess the VDI clones: Firstly,VDS can be integrated into theMicrosoft VDI architecture – as

already mentioned – so that theusers can communicate with theVDIs via this infrastructure. Onthe other hand – and this solutionis very interesting for smallerenvironments for which theinstallation and maintenance of acorresponding Microsoftenvironment would be toocomplex – DataCore alsoprovides a web interface thatallows access to the VDIs viatheir browser.

This web interface can beinstalled on IIS, but it mustsupport ASP.NET. Forcommissioning of the webinterface, it is by and largesufficient to copy the"WebPortal" files delivered byDataCore into separate folders toadjust the configuration file (therelevant steps are explained indetail in the documentation) andto register the web page in IIS.

The end user portal and theadministration page of theDataCore web interface are thenavailable via the URLs"http://address of the server" or"http://address of theserver/admin".

If administrators log into theAdministration portal with thedefault credentials"admin/admin", they arrive at anadministration page that allowsthem to add clones to the webportal, to view the clonesregistered in the portal and todisplay a list of the VDS hosts.

Additionally, the administratorand user accounts can beadministered via theadministration tool, a list ofmachines exported in CSVformat, email messages sent tothe users, and much more. In

5

Creating VDI clones with the aid of the relevant wizard

testing we first created a testuser, then added our clones to theweb portal and subsequently

allowed the test user account toaccess these VDIs. We thenswapped over to the web page forend users. Here users have theoption of using the machinesoffered via RDP, whichfunctioned in testing from thestart, to change the machinenames and to add a machinedescription, as well as an alias.

In addition, they can adapt theiruser profile with name, address,telephone number, password andthe like. The web interfacefunctioned from the start, asexpected. Its scope of features islimited to the most importantones though, but this makes theadministration of the productvery simple.

SummaryThe Virtual Desktop Server 2.0from DataCore is quick to set up,works reliably and manages withrelatively modest hardware. Thedeployment of the virtual storagestruck us as very positive, as this

ensures an efficient utilisation ofthe storage components that areavailable and simplifies the

administration at the same time.The wizards were clear and theydeserve particular mention, asthey make the creation and

management of the virtualdesktops easy, even forinexperienced administrators.

The monitoring tools also made apositive impression. The sameapplies to the web interface andthe support of the Microsoft VDIenvironment.

Both these access technologiesenable seamless deployment ofVDS in large environments, aswell as the uncomplicatedprovisioning of VDI clones insmaller networks. Also, the factthat the clones provided by VDSare stateful should be positivelyhighlighted once more, as thisbehaviour is expected by mostusers during operation.

The resulting summary of ourtesting is that DataCore VDS, incomparison to many othersolutions, is relatively simple toinstall, provides a high degree ofperformance and hardly makesany demands during operation.Consequently, we can thoroughlyrecommend the product – not just

for large installations, but also forsmall and medium­sizedenvironments.

6

Accessing a Windows 7 clone via the DataCore Web Portal

VDS as part of the Microsoft VDI environment