Home > Blogs > VMware Consulting Blog > Tag Archives: virtual desktop

Tag Archives: virtual desktop

Simple VDI Load Testing with View Planner

Jack McMichaelBy Jack McMichael, Solutions Consultant

In the last few years it seems the number of customers asking for assistance in re-evaluating their “VDI 1.0” infrastructure is increasing at a faster rate than ever. It makes sense when you consider that in the rush to achieve datacenter consolidation many administrators were under pressure to just “make it happen.” Many of those administrators and architects didn’t have time to design their virtual desktop infrastructure (VDI) solution to scale and accommodate things our customers and users have grown accustomed to using every day, such as YouTube HD, Skype, and other resource-intensive applications.

Last year, VMware released their very popular internal tool View Planner for use to the general public for free. While it’s flown under the radar for a lot of customers, it can be an invaluable tool for judging where your VDI solution stands, and identifying where the stress cracks in your VDI infrastructure may be forming—or are already wide open.

The View Planner appliance is simple to install and fairly straightforward to set up for local tests. It’s capable of local-only load testing, as well as passive/remote connections with the VMware Horizon® Client.

Deploying View Planner

After deploying an Open Virtual Appliance in VMware vSphere®, configure your View Planner integrations in the Config tab of the administrator page. The AD and View integrations are optional, but can be used if you wish View Planner to deploy desktops and/or create and delete users.

Note that for best results, I recommend using IP addresses instead of hostnames. Create a service account for your credentials, and give it administrator privileges in both AD and in VMware vCenter™.

In this screenshot, you can see all three connectors configured. You can use the Test buttons to ensure the configuration works, but click Save first.

JMcMichael 1

Environment Preparation

For my simple test, I created a linked clone pool with the name VPDesktop-{n:fixed=3} in VMware Horizon View™. On this master snapshot, I added the View Planner Desktop Agent that you can download from the View Planner portal on the Packages tab.

Make sure you reboot your desktop before creating your snapshot. Once you reboot, you will likely see the desktop auto-login. If so, run the View Planner Agent as seen in this screenshot.

JMcMichael 2

 

Configuring Run Profiles

There are three test modes available: Local, Passive and Remote. Typically, Local mode will be used for load testing since it doesn’t require actual Horizon Client connections, but has the disadvantage of not replicating PCoIP performance impact. Passive mode will add PCoIP connections that are shared amongst client servers that host more than one client connection at a time. Remote mode will create a 1:1 relationship between clients and desktops, thus creating the most overall resource impact.

To configure a Run Profile for a simple load test, I recommend using Local as it doesn’t require the use of the Horizon Client, and is also easy to set up. Simply add the Workload profile you want to run into the Run Profile by clicking Add Group, and click Save to save the Run Profile. You can add multiple workload profiles if you desire, but for a simple test only one is required.

The most important thing to remember is that desktop names (and client names if you choose Passive or Remote) are case-sensitive. In this example, VPDesktop– is valid for VPDesktop-001, but not vpdesktop-001 or VPDesktop001.

JMcMichael 3

Running a Test

Simply click the Run button to start a test. If you run into trouble, View Planner will show you right away; by clicking the link on the appropriate box, you’ll see the exact error or success message.

JMcMichael 4

 

Once completed, you can view the results in the Per Stats column; they will look something like the example below.

JMcMichael 5

Summary

Overall, I found the View Planner tool to be great for simple and quick tests of a VDI environment. It shows you where resource contention exists, or singles out how an app may be creating resource gaps in your VMware ESXi™ hosts. The free downloadable version includes several standard templates that cover a variety of normal user application workloads. If you require more flexibility in your tests, a paid VMware Professional Services engagement offers a more feature-rich version to create customizable workload profiles and other goodies. Contact VMware Professional Services or a VMware Partner for an on-site evaluation.

 


Jack McMichael is a Solutions Consultant for the VMware Professional Services Engineering Global Technical and Professional Services team. Follow him on Twitter @jackwmc4 !

App Volumes AppStacks vs. Writable Volumes

By Dale Carter, Senior Solutions Architect, End-User Computing

With the release of VMware App Volumes I wanted to take the time to explain the difference between AppStacks and Writable Volumes, and how the two need to be designed as you start to deploy App Volumes.

The graphic below shows the traditional way to manage your Windows desktop, as well as the way things have changed with App Volumes and the introduction of “Just-in-time” apps.

DCarter AppVolumes v Writable Volumes 1

 

So what are the differences between AppStacks and Writable Volumes?

AppStacks

An AppStack is a virtual disk that contains one or more applications that can be assigned to a user as a read-only disk. A user can have one or many AppStacks assigned to them depending on how the IT administrator manages the applications.

When designing for AppStacks it should be noted that an AppStack is deployed in a one-to-many configuration. This means that at any one time an AppStack could be connected to one or hundreds of users.

DCarter AppVolumes v Writable Volumes 2

 

When designing storage for an AppStack it should also be noted that App Volumes do not change the IOPS required for an application, but it does consolidate the IOPS to a single virtual disk. So like any other virtual desktop technology it is critical to know your applications and their requirements; it is recommended to do an application assessment before moving to a large-scale deployment. Lakeside Software and Liquidware Labs both publish software for doing application assessments.

For example, if you know that on average the applications being moved to an AppStack use 10 IOPS, and that the AppStack has 100 users connected to it, you will require 1,000 IOPS average (IOPS pre-user x number of users) to support that AppStack; you can see it is key to designing your storage correctly for AppStacks.

In large-scale deployments it may be recommended to create copies of AppStacks and place them across storage LUNs, and assign a subset of users to each AppStack for best performance.

DCarter AppVolumes v Writable Volumes 3

 

Writable Volumes

Like AppStacks, a Writable Volume is also a virtual disk, but unlike AppStacks a Writable Volume is configured in a one-to-one configuration, and each user has their own assigned Writeable Volume.

DCarter AppVolumes v Writable Volumes 4

 

When an IT administrator assigns a Writable Volume to a user, the first thing the IT administrator will need to decide is what type of data the user will be able to store in the Writable Volumes. There are three choices :

  • User Profile Data Only
  • User Installed Applications Only
  • Both Profile Data and User Installed Applications

It should be noted that App Volumes are not a Profile Management tool, but can be used alongside any currently used User-Environment Management tool.

When designing for Writable Volumes, the storage requirement will be different than it is when designing for AppStacks. Where an AppStack will require all Read I/O, a Writable Volume will require both Read and Write I/O. The IOPS for a Writable Volume will also vary per user depending on the individual user and how they use their data; it will also vary depending on the type of data the IT administrator allows the user to store in their Writable Volume.

IT administrators should monitor their users and how they access their Writable Volume; this will help them manage how many Writable Volumes can be configured on a single storage LUN.

Hopefully this blog helps describe the differences between AppStacks and Writable Volumes, and the differences that should be taken into consideration when designing for each.

I would like to thank Stephane Asselin for his input on this blog.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

App Volumes AppStack Creation

Dale CarterBy Dale Carter, Senior Solutions Architect, End-User Computing

VMware App Volumes provide just-in-time application delivery to virtualized desktop environments. With this real-time application delivery system, applications are delivered to virtual desktops through VMDK virtual disks, without modifying the VM or applications themselves. Applications can be scaled out with superior performance, at lower costs, and without compromising end-user experience.

In this blog post I will show you how easy it is to create a VMware App Volumes AppStack and how that AppStack can then be easily deployed to up to hundreds of users

When configuring App Volumes with VMware Horizon View an App Volumes AppStack is a read-only VMDK file that is added to a user’s virtual machine, and then the App Volumes Agent merges the two or more VMDK files so the Microsoft Windows operating system sees the files as just one drive. This way the applications look to the Windows OS as if they are natively installed and not on a separate disk.

To create an App Volumes AppStack follow these simple steps.

  1. Log in to the App Volumes Manager Web interface.
  2. Click Volumes.
    DCarter Volumes
  3. Click Create AppStack.
    DCarter AppStack
  4. Give the AppStack a name. Choose the storage location and give it a description (optional). Then click Create.
    DCarter Create AppStack
  5. Choose to either Perform in the background or Wait for completion and click Create.
    DCarter Create
  6. vCenter will now create a new VMDK for the AppStack to use.
  7. Once vCenter finishes creating the VMDK the AppStack will show up as Un-provisioned. Click the + sign.
    DCarter
  8. Click Provision
    .
    DCarter Provision
  9. Search for the desktop that will be used to install the software. Select the Desktop and click Provision.
    DCarter Provision AppStack
  10. Click Start Provisioning.
    DCarter Start Provisioning
  11.  vCenter will now attach the VMDK to the desktop.
  12. Open the desktop that will be used for provisioning the new software. You will see the following message: DO NOT click OK. You will click OK after the install of the software.
    DCarter Provisioning Mode
  13. Install the software on the desktop. This can be just one application or a number of applications. If reboots are required between installs that is OK. App Volumes will remember where you are after the install.
  14. Once all of the software has been installed click OK.
    DCarter Install
  15. Click Yes to confirm and reboot.
    DCarter Reboot
  16. Click OK.
    DCarter 2
  17. The desktop will now reboot. After the reboot you must log back in to the desktop.
  18. After you log in you must click OK. This will reconfigure the VMDK on the desktop.
    DCarter Provisioning Successful
  19. You can now connect to the App Volumes Manager Web interface and see that the AppStack is ready to be assigned.
    DCarter App Volumes Manager

Once you have created the AppStack you can assign the AppStack to an Active Directory object. This could be a user, computer or user group.

To assign an AppStack to a user, computer or user group, follow these simple steps.

  1. Log in to the App Volumes Manager Web interface.
  2. Click Volumes.
    DCarter Volumes Dashboard
  3. Click the + sign by the AppStack you want to assign.
  4. Click Assign.
    DCarter Assign
  5. Search for the Active Director object. Select the user, computer, OU or user group to assign the AppStack to. Click Assign.
    DCarter Assign Dashboard
  6. Choose either to assign the AppStack at the next login or immediately, and click Assign.
    DCarter Active Director
  7. The users will now have the AppStack assigned to them and will be able to launch the applications as they would any normal application.
    DCarter AppStack Assign

By following these simple steps you will be able to quickly create an AppStack and simply deploy that AppStack to your users.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

Analyzing Virtual Desktop Login Time

By Gourav Bhardwaj with Matt Larson

GouravMatt LarsonOften when performing health checks a discussion arises about the login time and what constitutes login time. This article covers some of the common ways to look at login time and its underlying components.  You can look at login time using vCOps for View or a third-party user experience monitoring solution. In this example the login time is demonstrated using Stratusphere™ UX. Experienced system administrators can also use this process to troubleshoot slow login times.

 

 

Review Virtual Desktop login times using Stratusphere UX™

  1. First, ensure you are in the Stratusphere UX Interface.
    Stratusphere UX screen 1
  2. On the Inspector tab, choose Machine Diagnostic Summary, and then click Go.
    Stratusphere UX screen 2
  3. In the Date Range drop-down menu, select Last 24 Hours.Stratusphere UX screen 3
  4. In the results list, sort by Login Delay.Stratusphere UX screen 4
  5. Click the down-arrow next to the name of the machine. Click Drill-down to see machine inspection history.
    Stratusphere UX screen 5
  6. Select the down-arrow next to the hour that contains the slow login time. Click Drill-down to see inspection report details.
    Stratusphere UX screen 6

A lot of information will be provided, including the username of the user experiencing the issues, as well as information regarding processes. One important piece of information used to find what may be causing the slow logins is the CPU System Time(s) field. The graphic below shows VMWVvpsvc running long. This metric indicates some login slowness resulting from the profile being copied from the profile location using VMware’s persona management. This may be the result of a file server being in a location local to the user, but not local to the View environment.

Stratusphere UX screen 7

This information is helpful, as it says that the VMWVvpsvc was running for 94 seconds. We can assume this is mostly during login, but that only accounts for 94 seconds of a 351 second login delay. Clearly, more information is necessary. While turning to logs can be helpful (such as persona management, the system event log, the application event log, and various View and PCoIP logs), they can be time consuming to review, and often the information these logs provide is insufficient.

Using the Windows Performance Toolkit
The Windows Performance Toolkit is a set of tools provided in the Windows SDKs for both Windows 7 and Windows 8. It consists of two high level toolsets: A toolset to gather information, and a toolset to analyze information. Once users and systems have been found to have slow login times, the toolsets provided with the Windows Performance Toolkit can be employed to further ascertain what exactly is causing the slow logins.

Installation
This section details the installation process to get the tools on the system that is experiencing slow login times. This process assumes the use of the Windows 7 SDK. Below are the steps:

  1. Remove Visual C# 2010 – this may or may not be necessary. If the C# version of the vSphere Client is installed on the workstation, then that existing installation of Visual C# 2010 will need to be removed. Not to worry, the SDK puts C# back on there, and there is no impact to the vSphere client or other applications that may use Visual C# 2010.
  2. Install the Windows 7 SDK – this can be done HERE. Launch the winsdk_web.exe file and ensure that at least the Windows Performance Toolkit is selected, and then click Next. Once the installation has completed, move on to the next step.Windows SDK screenNote: In order to analyze Windows crash dumps (AKA BSOD) I keep the Debugging Tools for Windows installed as well.
  3. Install .NET 4.0 – this can be done from HERE. Again, this depends upon whether or not it is installed on the workstation in question.

This completes the installation. The installation can be verified by confirming that the program group exists on the Start Menu, or navigating to the installation directory, which defaults to C:\Program Files\Microsoft Windows Performance Toolkit, and confirm the existence of xbootmgr.exe and xperf.exe as seen in the images below.

Windows Screen 2Windows Screen 3

Using XPERF
The process to use XPERF to gather information regarding slow logins is as follows:

  1. Enable fast user switching in the registry or GPO.
  2. Create a local user account named Test, and add to the local administrators group. (Using an administrative user that is not the problematic user will also work.)
  3. From the console of the problematic workstation, log in as the user with administrative privileges.
  4. Launch a command line with elevated privileges, and navigate to C:\Program Files\Microsoft Windows Performance Toolkit.
  5. Launch the XPERF command:
    1. XPERF Command: xperf -on base+latency+dispatcher+NetworkTrace+Registry+FileIO -stackWalk CSwitch+ReadyThread+ThreadCreate+Profile -BufferSize 128 -start UserTrace -on “Microsoft-Windows-Shell-Core+Microsoft-Windows-Wininit+Microsoft-Windows-Folder Redirection+Microsoft-Windows-User Profiles Service+Microsoft-Windows-GroupPolicy+Microsoft-Windows-Winlogon+Microsoft-Windows-Security-Kerberos+Microsoft-Windows-User Profiles General+e5ba83f6-07d0-46b1-8bc7-7e669a1d31dc+63b530f8-29c9-4880-a5b4-b8179096e7b8+2f07e2ee-15db-40f1-90ef-9d7ba282188a” -BufferSize 1024 -MinBuffers 64 -MaxBuffers 128 -MaxFile 1024
  6. Using fast user switching, switch users, and login as the problematic user.
    1. Once the login has completed, stop the trace using the following command:
      xperf -stop UserTrace -d merged.etl
  7. Gather the merged.etl trace file for analysis.

Using XBOOTMGR
In some cases, it may not be possible to switch users using fast user switching. In many cases, it may be easier to have the user run XBOOTMGR. This tool, when run, reboots the system and tracks both the startup time and the login time. The analysis ends after a set period of time. Gather an XBOOTMGR analysis by performing the following:

  1. Launch a command line with elevated privileges, and navigate to C:\Program Files\Microsoft Windows Performance Toolkit.
  2. Run the following command:
    1. XBOOTMGR Command: xbootmgr -trace boot -traceflags base+latency+dispatcher -stackwalk profile+cswitch+readythread -notraceflagsinfilename -postbootdelay 120
  3. The system will prompt that it is being rebooted. Allow the reboot to occur.
  4. When the VM is started, have the user connect to the View desktop using the View client.
  5. When the user logs in, XBOOTMGR will present the user with a countdown of 120 seconds. Allow XBOOTMGR to collect data.
  6. Once complete, gather the *.etl trace file for analysis. It may take some time to merge the file.

Analysis
The trace file has been created, and now it is time to analyze the results. The analysis toolset available in the Windows 7 Performance Toolkit is slightly different than what is available in the Windows 8 Performance Toolkit.

Performance Analyzer from Windows 7 Performance Toolkit

Open with Performance Analyzer (From the Windows 7 Performance Toolkit)
Windows Performance Analyzer
The graph below shows the processes occurring during the Winlogon Init process. It is easy to see that VMWVvpsvc is running for approximately two minutes.
Windows Performance Analyzer Screen 1

By right clicking on the graph, one can Overlay Graphs from other categories. This graph shows the Winlogon process, as well as the overlay graphs for Boot Phases and CPU Usage. This can be helpful to see which boot phase the processes are running. Additionally, the CPU graph will show whether the process is running long because it has maxed out the available CPU capacity.
Windows Performance Analyzer Screen 2

These overlays can be tweaked by selecting the CheckPoints box in the top right corner of the graph.

CheckPoints Dialog
Windows Performance Analyzer from Windows 8 Performance Toolkit

Open with Performance Analyzer (From the Windows 8 Performance Toolkit).  The icon is shown below:

Windows8

Windows Screen

When looking at the same trace file as before, the graphs show that VMWVvpsvc was running for over 2 minutes. Moving the user files closer (from a network perspective) to the View desktop will help reduce the login time.

References
http://social.technet.microsoft.com/wiki/contents/articles/10128.tools-for-troubleshooting-slow-boots-and-slow-logons-sbsl.aspx

http://www.liquidwarelabs.com/products/stratusphere-ux


Gourav Bhardwaj is a VMware consulting architect who has created virtualized infrastructure designs across various verticals. He has assisted IT organizations of various Fortune 500 and Fortune 1000 companies, by creating designs and providing implementation oversight. His experience includes system architecture, analysis, solution design and implementation.

Matt Larson is an experienced, independent VMware consultant working in design, implementation and operation of VMware technologies. His interests lie in enterprise architecture related to datacenter and end user computing.

End User Computing 101 and Tips for Successful Deployments

By TJ Vatsa, Principal Architect, VMware Professional Services

TJ VatsaThe topic of End User Computing (EUC) is heating up. This is not only because our industry considers this to be a dynamic domain for tremendous innovation today, but also because the industry views great potential for the future and is heavily investing in the space.

In this three-part blog series, I’ll assimilate the vast EUC landscape into digestible tidbits that focus on the infrastructure, mobility and BYOD, applications and image management, and discuss a typical EUC project scenarios and methodology.

My goal is to provide insight into the things you should consider for your own EUC deployment.

EUC Landscape

First Things First: Infrastructure

As soon as someone mentions EUC, the first thing that comes to mind is Virtual Desktop Infrastructure (VDI). The very fact that VDI is deployed in the datacenter, away from individual desktops, means that you must plan the underlying infrastructure in a systematic and thorough way.

At a minimum, this means allocating key infrastructure resources: compute, storage, network, and security.
It is also imperative that some sort of infrastructure resource assessment tools be deployed to establish a baseline for each of these infrastructure components.

Desktop and Server Power

Assuming that a baseline has been established for the compute resources in terms of CPU, clock speed, and memory requirements per desktop, it is important to choose a server configuration with the right processor, clock speed, and physical memory. In turn, this drives the correct consolidation ratio of virtual desktops per core and, ultimately, for the entire server.

Give careful attention to different use cases where specific workloads require different combinations of CPU, clock speed, and memory. You must ensure that you also plan for growth and seasonal/occasional bursts seen in those workloads historically.

For a typical Horizon View deployment, there are two categories of VMs (virtual machines) recommended for deployment inside the data center: one for management purposes and another for desktop purposes. Management VMs are mainly servers (connection brokers, databases, etc.) whereas the desktop VMs are the actual virtual desktops.

For a production deployment, VMware recommends creating two separate cluster types–Management Cluster(s) and Desktop Cluster(s)–to avoid any race conditions that might arise as a result of, say, competing workloads or operational maintenance.

Storage: Key to VDI Success

Having worked with many customers across many different industry verticals (healthcare, financial, entertainment services, and manufacturing) I’ve noticed that there’s one critical success factor in common: storage.

For more information about VDI storage and detailed insight into what is important for a successful VDI deployment, read these two blog posts:

Part I: Storage Boon or Bane – VMware View Storage Design Strategy & Methodology
Part II: Storage Boon or Bane – VMware View Storage Design Strategy & Methodology

In my next post, I’ll cover the remaining considerations around a successful VDI deployment, including network and security, converged appliances, and desktop as a service. Stay tuned!


TJ has worked at VMware for the past four years, with over 20 years of experience in the IT industry. At VMware TJ has focused on enterprise architecture and applied his extensive experience to Cloud Computing, Virtual Desktop Infrastructure, SOA planning and implementation, functional/solution architecture, enterprise data services and technical project management.

TJ holds a Bachelor of Engineering degree in Electronics and Communications from Delhi University and has attained multiple industry and professional certifications in enterprise architecture and technology platforms. TJ is a speaker and a panelist at industry conferences such as VMworld, VMware’s PEX (Partner Exchange) and BEAworld. His passion is the real-life application of technology to drive successful user experiences and business outcomes.

Horizon View: RDS PCoIP Design Tips

By Dale Carter, Consulting Architect, End-User Computing

With the release of VMware Horizon View has come the ability to not only configure virtual desktops but also virtual applications hosted on Windows RDS servers.

In this post, I will cover a couple of things that you should take into consideration when configuring virtual applications and how they might affect the sizing of your View Cluster and the number of connection servers you will need.

There are many different papers and posts on how to configure RDS servers themselves, so I will not be touching on that in this post. I want to discuss the effects of how the PCoIP connections connect to RDS servers and what you should look out for.

Scenario 1
The following diagram shows my first configuration. This includes a virtual desktop cluster and a single RDS farm. RDS Farm A in this example is hosting five applications: Word, Excel, Power Point, Visio and Lync.

Virtual Desktop Scenario 1

In this scenario if a user launches a virtual desktop and then an application, the user would be using a maximum of two PCoIP connections through the Horizon View infrastructure. It’s important to know that when configuring RDS with just one farm, if a user then launches a second application or all five applications, then all these applications will launch using the same PCoIP connection. This means that all five applications for that user would be running on the same RDS host. In this scenario, you need to make sure that each of your RDS hosts can handle all users opening all applications on each of the hosts.

The Horizon View connection servers do load balance a user’s connection when the user first connects to an RDS host. Users will always be sent to the RDS host with the lowest number of connections; however, once they are connected they will always go to the same RDS host until they completely disconnect from all applications.

In this scenario, if you have 300 users and they all launch Word, each RDS server will have 100 connections all running Word. It is also possible in this scenario that Servers A and B will only be running 100 instances of Word; whereas Server C could be running 100 instances of all five of the different software applications. This is why it is critical that the RDS servers are configured correctly.

Scenario 2
In the second configuration, I split the application across RDS host farms. The following diagram shows two RDS farms. The first, Farm A, is hosting Word, Excel and PowerPoint. The second, Farm B, is hosting Visio and Lync.

Virtual Desktop Scenario 2

 

Now in this scenario, if a user launches a virtual desktop and then the applications Word and Visio, we have managed to lighten the load on the RDS servers. By separating the application into different RDS farms, we now know that each RDS server is not going to get as much load when a user opens these applications. However, instead of a user only using two PCoIP connections the user is now using three PCoIP connections.

Conclusion
Given this information, it becomes more important than ever to know your users’ environment and the applications the users are using. When deploying Horizon View into your environment and taking advantage of the new hosted application functionality you need to ask yourself the following questions:

  • How many applications will be installed on each RDS host?
  • What is the hardware configuration of the RDS host?
  • How many RDS farms will be required?
  • How many PCoIP sessions will each user require?

For larger environments, the question might be: Will one or more View deployments be required? As the environments get larger, it might be a better design to have one View deployment for desktop connections and a separate deployment for hosted applications. In this scenario, VMware Workspace can become that central location for users to access all of their desktops and applications. With VMware Workspace 2.0, it is now possible to configure more that one View environment, giving you the option of multiple View environments that are all accessible from the one Workspace front end.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy