Important Questions in Implementing Virtual Desktops

1
Article 1: Where Do I Start with Virtual
Desktops?
Virtualization by itself is a mature and smart move for the business data center.
Compressing large numbers of physical servers into small numbers of virtual hosts, the
move to virtualization reduces the raw costs of running a data center while improving your
management of individual servers.
Yet virtualization needn’t necessarily stop with the conversion of servers to virtual servers.
Its enhancements to overall systems administration and reductions in cost play equally
when virtualizing user desktops. The very same virtualization infrastructure you use for
your servers today can be naturally extended to support the hosting of desktops as well. As
a result, users gain the flexibility of connecting to a well‐managed desktop from virtually
any network endpoint. The business reduces its overall costs in maintaining its distributed
computing infrastructure. And your IT organization gains previously‐unseen levels of
security and control that arrive as a function of centralization.
But how do you get there? What exactly are virtual desktops and how are they presented to
their users? What technologies, both hardware and software, are necessary to achieve this
end goal? What are today’s best use cases for deployment? This series will attempt to
answer these important questions in implementing virtual desktops, leaving you with the
right set of information to make an educated decision about extending your own virtual
infrastructure.
What Is a Virtual Desktop?
Simply put, a virtual desktop is a virtual machine. These operating system (OS) instances
are the very same kinds of virtual machines that you may already host atop virtual
platforms, such as VMware vSphere or ESX. As a virtual machine, a virtual desktop
automatically enjoys the same kinds of workflow and consolidation benefits as do all types
of virtual machines:
• Multiple virtual desktops can be hosted on a single physical server, increasing
utilization of existing hardware.
• A virtual desktop’s initial configuration is often based on a reference image, making
possible its rapid and automated deployment.
• Being hosted within your protected data center, and with only screen updates and
mouse/keyboard commands traversing the network, their data is dramatically more
secure than in a traditional distributed infrastructure.
• As an instance that is designed for remote access, users can access their full‐fidelity
desktop from any network connection.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
2
The primary difference between a virtual desktop and a virtual server lies within its OS and
end user. Virtual servers are used for processing workloads in the data center, such as file
services, email services, databases, and network applications. Virtual desktops are
instances of desktop OSs such as Windows XP, Windows Vista, and Windows 7. Their end
user is the individual employee in your organization, with each virtual desktop supporting
the processing needs of one individual. Different than a physical desktop, a virtual desktop
is connected to via the network using some form of endpoint technology. That network can
be either the local LAN or WAN, or, with the proper routing and security in place, it can also
be the Internet.
This one‐to‐one ratio between virtual desktop and user is fundamentally different than the
architectures used by other remote access solutions such as Microsoft’s Terminal Services
or Citrix’s XenApp. Within these products, application use is shared by multiple users on
the same server. Thus, the same instance of Microsoft Word is leveraged by every user
using that application on that server.
Although this type of access is good with the right kinds of applications and when
application needs are slight, many applications simply do not function in a multi‐user
environment. Also, applications with high resource needs tend to experience overload
conditions in these environments, which reduces the overall user experience. Most
importantly, these environments require a high level of administrative control in order to
keep collocated users from stepping on each other, which limits users’ ability to customize
their environments to their liking. Virtual desktops make sense when fullfidelity
desktops
are necessary for users, with each user enjoying their own individual OS instance that is not
shared with others.
Types of Virtual Desktops
Considering the previous statement, there are in fact a number of architectures by which
full‐fidelity desktops can be delivered to users. Depending on the needs of your users, any
of these may make sense for your business:
• Assigned desktops. The assigned desktops architecture fits well in environments
that want the highest level of desktop configurability for users. In this environment,
a virtual desktop is created and specifically assigned to each user. When a user
connects into the virtual desktop infrastructure, the user always receives the same
desktop. Because desktops are assigned, one‐off applications can be installed for
specific users, and users can customize their desktop instances according to their
needs.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
3
• Pooled desktops. Environments that leverage a more standardized set of
applications can enjoy a more efficient use of resources by pooling desktops. In this
architecture, a set of desktops is made available for concurrently‐connecting users.
As no assignment of user to desktop is made, any user may randomly connect to any
desktop. Desktops are preloaded with necessary applications, and limited state
information is injected onto the desktop as part of the login operation. In this
environment, it is often the case that a smaller count of desktops is necessary, as the
number of available desktops need only meet the concurrent user count rather than
the total user count. Further, as pooled desktops are deployed with the assumption
of random assignment, it is easier to refresh the pool en masse when updates are
required.
• Kiosk/lab desktops. Virtual desktops provide a significant advantage to kiosk and
lab environments due to their ability to be quickly refreshed, deleted, and re‐created
on demand. This is particularly the case in low‐security kiosk and lab environments
where desktop refreshes are necessary and often must be accomplished with short
notice and within a short timeframe. Here, entire labs can be quickly rebuilt to
support new missions through a few mouse clicks.
• Converted desktops. This scenario is similar in delivery to assigned desktops but is
different in that users’ original physical desktops are converted to virtual desktops
through some mechanism. These desktops are then operated with the same
configuration as the original desktops but function with the benefits of virtual
desktops. This architecture tends to enjoy the lowest level of automation flexibility
because individual desktops are not created from a central source. Further, directly
converting physical desktops to hosted desktops is an option that is typically only
considered on an exception basis due to their inherent lack of commonality.
In all of these scenarios, a primary management benefit relates to the ability to rebuild any
virtual desktop instance on demand. A virtual desktop arrives as the combination of a
reference desktop image, installed applications, injected user personality information, and
connections to documents and files (see Figure 1). These four elements are laid down using
an automated interface:
• The desktop’s OS image is copied from a reference image, creating the base OS
environment for the desktop.
• Applications that are not already part of the reference image are installed
automatically to the desktop.
• The user’s individual personality configurations such as desktop and Internet
shortcuts, backgrounds, colors, and any other customization are injected into the
image as the user connects to it.
• Any files needed by the user and stored on alternative servers are connected
through drive mappings or shortcuts.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
Figure 1: Provisioning a new virtual desktop involves the automated invocation of
four steps.
This means that the entire set of user‐specific data can be rolled from one instance to
another at will. Should a user experience a problem with his or her desktop—if its
configuration is corrupted or if it is inadvertently or maliciously infected with malware—
an administrator needs only to re‐provision a new virtual desktop image to the user.
Where to Start?
Due to their flexibility, virtual desktops can be rolled out to an organization using
essentially any plan that works for the business. A business can elect to roll out virtual
desktops to a select group of individuals first, while slowly implementing them for others
in the organization. Virtual desktop rollouts can be further implemented based on the
capacity of the virtual infrastructure. As your business incrementally transitions resources
from physical purchases to a virtual infrastructure, more processing power and client
endpoints can be implemented into the environment. This horizontal scaling of resources
enables more users to move to virtual desktops.
For environments that aren’t ready for full conversion, virtual desktops needn’t necessarily
operate as full desktop replacements. Virtual desktops leverage the same network
infrastructure as distributed physical desktops, so users can leverage virtual desktop use
for specialized circumstances such as work‐from‐home situations or in maintaining
operations during a disaster. Article three will talk more about some of these potential
situations and their benefits.
4
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
5
Virtual desktops also make sense in limited implementations when users are highly mobile
in their workday patterns. For example, doctors and nurses in hospitals or students in
university settings, both of which involve users who must connect multiple times per day in
multiple locations. Call centers are excellent targets for a virtual desktop infrastructure
because of their limited application set, highly mobile workforce, and limited need for
desktop customization.
In the case of call centers as well as in the retail sector, virtual desktops have a large
advantage over alternative remote application infrastructures due to their extensive
support of peripherals. Unlike traditional remote application infrastructures, which tend to
have limited support for point‐of‐sale and call center peripherals, virtual desktops that
leverage the right kind of client endpoint can use any peripheral that is supported by the
virtual desktop’s OS.
Virtual Desktops Solve Many IT Problems
You can see in this article that a virtual desktop infrastructure has the potential to solve
many of the administrative nightmares faced by IT. Centralizing the otherwise distributed
desktop infrastructure means tighter security, easier administration, and more rapid
problem resolution. At the same time, it enables desktops to be presented to users no
matter where they may be located.
The next step is in implementing its technologies. There is no single product or technology
that represents an entire virtual desktop infrastructure. Instead, getting to this
management nirvana requires the integration of a set of technologies from virtualization
infrastructures to client endpoints. Solutions that offer out‐of‐the‐box integration of
principal components can significantly accelerate the successful deployment of virtual
desktops within an organization. Article two in this series will outline what you’ll need for
your own infrastructure.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
Article 2: What Technologies Are Critical
for Virtual Desktop Success?
Virtualization, orchestration, personality management, servers and storage, and the allimportant
endpoint—these are technologies you must integrate to create a successful
virtual desktop infrastructure. The first article in this series closed with the statement that
today’s virtual desktops encompass no single technology. There is no shrink‐wrapped box
of software that you can buy to Next, Next, Finish your way to a virtual desktop
environment. Instead, multiple technologies must be integrated in careful ways to create
the necessary architecture.
But don’t let this statement scare you. The multi‐product approach to creating an IT
infrastructure of any type isn’t a new technique. Even mature technologies such as email
and file services require multiple products to be successful. As an example, an email server
requires the server to function but also requires the addition of anti‐spam, anti‐malware,
proxying, and often multiple additional servers in larger environments to correctly
accomplish its mission. With virtual desktops, it is likely that you already have many of its
components or the capacity to host them in place.
What Are the Prerequisites for Virtual Desktops?
Figure 1 outlines a few of the components necessary to stand up your initial virtual desktop
infrastructure. Obviously, the first necessary component is a mechanism to actually
virtualize the desktops themselves. This enterprise virtualization platform should be able
to support a high level of virtual machine density, enabling large numbers of virtual
desktops to be hosted per configured server.
6
Figure 1: A virtual desktop is powered by a virtual host. It is accessed via a client
endpoint through many types of network connections.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
7
Also necessary in combination with that virtual platform are the servers that host virtual
machine processing. With an enterprise‐class virtualization platform and correctly
configured hardware, it is not unheard of to expect between five and eight virtual desktops
per server core. Each desktop can be configured with as little as 512MB of RAM for users
with light workloads such as minimal Microsoft Office utilization, or as much as 1GB or
more of RAM for heavier uses.
Note
Be cautious with the assignment of memory to virtual desktops, as
conservation of RAM is critical to ensuring the highest level of virtual
desktop density.
Disk performance in virtual environments can be a singular bottleneck when not properly
planned. As virtual machine processing is highly disk‐centric due to its entire configuration
being on disk, the rotation speed of disks used in virtual environments is exceptionally
important. High‐performance SAS or FC disks with a rotation speed of 15,000RPM or
greater is recommended to eliminate any disk bottlenecks, although slower drives (such as
those that operate at 10,000RPM) can be used for less‐demanding workloads if properly
monitored. The use of high‐speed disk controllers with efficient RAID is recommended to
ensure that the processing of disk requests can keep up with server processing.
Also critical is the speed of the network. Although a deficiency in any physical component
such as processor power or disk speed can cause a reduction in performance for the end
user, a well‐performing network is critical to the best user experience. Although not
technically a “streaming” technology, the connection between virtual desktop and user is
highly reliant on an uninterrupted and efficient stream of data. Latency either in the
network or as a function of a resource bottleneck is the greatest enemy of a virtual desktop
infrastructure. Any latency will be felt by users as sluggish performance and will result in a
reduction in the user experience. Most high‐speed business LANs should not experience
this problem; however, environments that span the Internet, multiple sites, campus
environments, and metro‐area environments must take care to architect the proper
amount of bandwidth to prevent latency effects.
As such, you must be cautious not to overload your virtual infrastructure with too many
virtual desktops. Although a virtualization platform can create effectively unlimited
numbers of virtual machines, the performance utilization and count of those virtual
machines must be closely monitored to ensure that each user retains an experience
equivalent to a local desktop.
Lastly are the personality management and orchestration components that ensure users
are correctly connected to the right virtual desktop and that user state is properly injected.
Orchestration components are typically made available through a virtual desktop
technology’s vendor, making each technology different in the mechanism by which users
are connected to desktops (more on this in a minute). Personality management
technologies typically leverage either Microsoft Windows Roaming Profiles or make use of
a third‐party application.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
8
How Do Users Interact with Virtual Desktops?
With all these pieces, we’re not quite done. It can be argued that of these components, the
most important to consider relates to the client endpoint itself. Essentially, some technology
must exist at the users’ network connection in order to interact with their virtual desktops.
Figure 1 shows how the display and interaction with a virtual desktop occurs over the
network. Transporting that data across the network occurs through one of many network
protocols, all of which are highly‐optimized for network utilization and preservation of the
user experience. Different virtual desktop vendors leverage different technologies for
delivering that interface to its users, and it is the selection of the right technology here that
will determine the success of your virtual desktop implementation.
To explain this statement, think for a minute about the elements that must be in place for a
user to access a virtual desktop. A virtual infrastructure must be in place to host that
desktop. The network must contain the capacity to support the network transport of its
interface. Management tools must be available for creating and administering the desktop
infrastructure. And, most importantly, some component must be in place at the user’s
location to receive the desktop.
It is the selection of this client endpoint component that ultimately makes or breaks a
virtual desktop deployment’s ROI. Cost models associated with hosted desktops gain much
of their financial benefit through the elimination of “real” desktops at the user’s location. By
eliminating the real desktop, the cost of maintenance and upgrade is eliminated, as is the
annual cost of administering the configuration, security, and application load‐out on that
endpoint.
However, with virtual desktops, one cannot simply eliminate the device at the client’s
location. Something must be present to receive the data for the virtual desktop and convert
it into a useable interface for the user. Accomplishing this task by using traditional desktop
computers eliminates much of the potential benefit gained by centralizing desktop
processing. Rather, needed is a specialized device that requires no configuration, retains no
onboard state, and can be swapped out as easily as the user’s desk or their telephone. Such
a device fulfills the need for an endpoint but does so while maintaining the ROI gained
through the total and complete centralization of desktop processing.
The Value of the Zero Client
Lacking any form of onboard configuration information, such a device could be considered
a completely stateless client, or a “zero client.” This moniker is used as a comparison with
early “thin client” devices. These devices interoperated with remote application
environments such as Terminal Services or XenApp. With a thin client, a minimal operating
system (OS) is stored on the client device itself. Its processing was used to connect the
client device to a remote access server for the deployment of applications.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
9
Thin clients grew in popularity towards the end of the last decade. Having very few moving
parts, these clients could be easily deployed and needed only minor updating—often
through flash RAM updates but sometimes via small onboard hard drives. Their primary
responsibility was to connect the user to their remote applications, present a user
interface, and send keyboard/mouse commands back to the server.
However, over time, many found that the promise of thin clients didn’t align with the
reality of their administration. With many thin clients, their minimal onboard OSs still
required updating, a process that consumed time and increased their cost to maintain.
Further, producers of thin client OSs weren’t often able to keep pace with changing
technology at the server side, forcing many thin client deployments to stick with older
server‐side technology. Even more problematic, when needed business applications were
found to not function atop Terminal Services or XenApp, businesses were often forced to
revert back to traditional desktops.
Contrast this situation to the virtual desktop alternative. Here, every part of a virtual
desktop’s processing (and indeed all its code) is retained at the server side and within the
virtual desktop itself. In this situation, the client is little more than an electrical transceiver,
one that converts electrical signals from an Ethernet cable that is connected to a common
TCP/IP network into useable signals for video, mouse, keyboard, and peripherals.
Such a client is entirely stateless, and as such, never needs updating, management, or
replacement of onboard code. When technology changes at the server side—alternative
virtualization hypervisors, new technologies in deployment, improvements in data
transport protocols, and so on—there is never a need to update individual clients.
Technology changes at the server side are immediately and automatically useable by
clients that are deployed into the field. The only necessary step to implement new
technology is in altering the server infrastructure.
Lastly, and most importantly, the virtual desktop infrastructure back in the data center
retains the 1:1 mapping between users and OS instances. This means that any application
that works on Microsoft Windows will work in the virtual desktop environment. Thus, it is
likely that your business will never be forced to revert back to traditional desktops because
of an application incompatibility.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
10
Multiple Technologies. Agile Processing.
There are a number of technologies that are required to create a virtual desktop
infrastructure. These technologies incorporate the consolidation power of virtualization
with the automation flexibility gained through OS management. With the right tools in
place, it is possible for users to connect to their desktops from anywhere with a network
connection. At the same time, problems in the environment can be solved with very little
effort. Although the initial costs of building such an environment can be high considering
the technology outlay that is required, such an expense can quickly pay for itself through
the reduction in operational expenditures over time.
Now that you understand the promise of virtual desktops as well as the technologies that
make them a reality, your final question likely relates to the use cases where it most makes
sense. Today’s implementations of virtual desktops work well across a range of
environments, with some gaining dramatic efficiencies. The final article in this series will
tell a set of stories from industries who have benefitted from their virtual desktop
implementations.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
11
Article 3: What Are Others Doing with
Virtual Desktops?
The first two articles in this series have attempted to answer the questions surrounding
“why” virtual desktops make sense for the business. The architectures and technologies
behind virtual desktops were explained in detail, showing how multiple technologies
aggregate to create a virtual desktop infrastructure.
But knowing that a thing can be done doesn’t necessary explain how and where it should
be done. This third and final article will attempt to answer those questions, detailing how
and where many organizations are currently and successfully using virtual desktops.
Delivered as a series of generalized case studies, this article will explain how a few
organizations have turned virtual desktops into a competitive advantage.
Case Study #1: Mobile Access Stations at a Hospital
ABC Hospital is a large hospital with multiple departments, all of which are served by a
centralized IT organization. The primary responsibility of the IT organization is in
maintaining the hospital’s data center as well as its unified patient service application.
Within this application are stored all forms of patient records, including prior admissions,
doctor notations and recommendations, prescribed drugs and interactions, as well as
imaging via x‐ray, MRI, or other devices. As the singular application that handles and
records virtually every facet of patient interaction, it is needed in every examination room
by multiple doctors and nurses.
The problem with ABC Hospital’s use of this application relates directly to the login process
required to connect doctors and nurses into the application. Because both groups of people
regularly move between offices, yet need access in each office to patient records via the
application, the time to connect must be minimal. ABC Hospital’s original attempts to
leverage traditional Windows logins and logouts with locally‐installed workstations often
required login and application startup times of multiple minutes. This was unacceptable to
both doctors and nurses, with the original system quickly being scrapped as alternatives
were sought.
Microsoft Terminal Services‐ and Citrix XenApp‐based solutions were also rejected due to
incompatibilities in the application itself. This application was developed for the healthcare
industry and was not created to be interoperable with traditional remote application
infrastructures.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
12
A workable solution was developed that leverages the rapid connection and disconnection
power of virtual desktops. As virtual desktops remain assigned to individual doctors and
were not logged off or powered down as doctors relocate from room to room, an individual
doctor can quickly connect to their assigned desktop with its applications already loaded.
To the doctors, the user experience appeared as if each monitor in each examination room
were independently connected to their personal desktop. Connection time was reduced to
a single‐digit number of seconds rather than the multiple‐minute requirements of the
physical desktop infrastructure. This improved the doctor/patient relationship, and even
saved a few lives over the course of its lifespan.
Case Study #2: Hot Desking at a Three‐Shift Call Center
ABC Call Center is a three‐shift call center that handles multiple clients. First‐ and secondshift
operators typically handle customer service activities across ABC Call Center’s client
list, with its third shift dealing with emergency situations. As a multiple‐shift environment,
employees use available desks during their 8‐hour shifts. This workflow means that any
particular hot desk is generally always staffed during the full 24 hours of the day.
In order to process calls, ABC Call Center leverages a central call center application. This
application presents the necessary scripts to employees as well as enables actions that can
be accomplished by the employee in resolving a customer problem. Because ABC Call
Center handles multiple clients at once, the same employee can handle requests across
multiple clients during any particular shift, with their individual scripts and actions being
presented to the employee by the application.
ABC Call Center originally leveraged the use of physical desktops at each hot desk. This
configuration enabled users to log in as they arrived for work, and log out as they
completed their shift. However, it suffered from a number of critical limitations. The
employees for ABC Call Center had a tendency to “play” with the desktops during irregular
downtime periods. This non‐work use of the systems regularly led to their need for
troubleshooting or re‐imaging. However, due to the high utilization of the call center as
well as its multiple‐shift nature, any downed computer meant one less employee handling
calls on the call room floor. Further, the installation of required updates to the individual
desktops created a substantial impact on operations.
To remedy this situation, ABC Call Center leveraged a set of zero clients that connected to a
pool of virtual desktops. Installed to those virtual desktops was the call center application.
They were further locked down to prevent known forms of non‐work use.
Because virtual desktops were used in a pooled configuration, any user automatically
received an arbitrary, available desktop. That desktop was always properly configured for
their use, because each was constructed on‐demand from a reference image as the
employee logged in. Updating the pool of images required updating only the reference
image and forcing a refresh of all virtual desktops in the pool, effectively provisioning any
update automatically at the next shift change. The result to ABC Call Center was a
substantial increase in worker efficiency and a reduction in costly downtime to nearly zero.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
13
Case Study #3: Training Lab at a University
ABC University is a large university with multiple departments. After a major centralization
activity, IT services for all departments were unified under a singular organization. This
enabled ABC University to consolidate its dozen computer labs into a single building that
could support the needs of all departments at a much lower operational cost.
However, quickly after the consolidation, it was found that the physical environment used
by the lab was insufficient for the rapid re‐provisioning needed by different faculty. For
example, a computer lab that was configured for use by a Foreign Languages professor
would be needed during the next teaching hour by a Computer Sciences professor for a
completely different class. Whereas the Foreign Languages professor’s class required only
a simple application, the Computer Sciences class might engage in wholesale manipulations
to the systems and the network. As a result, professors would regularly find that the
computer lab was insufficiently set up for their needs.
As a further need, the university found itself wanting to provide access to labs for users at
all hours and from all locations. This access would alleviate the strain on the actual
computer lab by allowing students to access lab equipment over the network and from
their dorm rooms.
A mechanism to accomplish both the rapid redeployment as well as the ubiquitous access
problem was needed. The creation of a virtual desktop infrastructure was eventually
decided upon by university IT. Such an infrastructure enabled lab administrators to create
and manage multiple reference images, one for each professor and class. With enough
processing power in the university’s data center, lab administrators were able to clone
dozens or even hundreds of images that were specifically created for each lab. This could
occur in the 10 minutes between one class ending and another starting. Professors with
needs for new images could simply create them according to a standardized process and
submit them to IT for uploading into the virtual desktop infrastructure.
Extending the early implementation to the rest of the university’s network infrastructure
required very little extra effort on the part of IT. A third‐party orchestration component
was customized by the university that enabled students to connect to any class’s virtual
desktop. Such a desktop could be cloned at any point during the day and would be available
for the student for a period of 4 hours before being automatically removed. User data was
gathered from any and all images prior to removal, enabling users to reconnect at their
leisure.
The result was a significant reduction in wait times for lab equipment as well as an increase
in student and professor satisfaction with the overall environment. Ultimately, both
professors and students found themselves needing less actual real‐time access to lab
equipment during the day, reducing power costs as well as the count of equipment
necessary to run the university’s classes.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
14
Case Study #4: Disaster Recovery Operations at a Corporation
ABC, Inc. is a multinational corporation with offices in the United States, EMEA, and Japan.
As a multinational corporation with very high‐end clients, its data processing had a
requirement of 99.95% uptime. Its customers were highly intolerant of both downtime and
any loss of data. This fact required ABC, Inc. to create and execute a disaster recovery plan
that assured continued access to data, even during disaster operations. Although ABC, Inc.
was able to replicate its data to multiple alternative sites, and was further able to replicate
its application servers to those sites, it found itself unable to connect employees to
necessary applications in the case of a disaster.
ABC, Inc. eventually settled on a virtual desktop solution as its architecture for disaster
operations. A virtual desktop infrastructure was implemented to support its most‐critical
30% of employees who were specifically targeted for continuing their work during a
disaster. The other 70% of employees were not deemed mission critical, which enabled
ABC, Inc. to incorporate a standby virtual desktop infrastructure of smaller size and cost.
Because ABC, Inc.’s virtual desktop infrastructure was hosted in a third‐party facility away
from its other operations, its mission‐critical users were configured to access their disaster
operations virtual desktops via the Internet. Users no matter where they were in the world
could access replicated ABC, Inc. data to continue the operations of the company.
Although this standby virtual desktop infrastructure was useful in the case of a disaster, it
was later leveraged during nominal operations for its field support teams. While in normal
operations, up to 30% of its workforce could securely and safely access ABC, Inc.’s most
critical business applications from any Internet endpoint. Ultimately, ABC, Inc. was able to
improve its agility through this implementation alone such that it was able to extend
operations in both EMEA and Japan where direct LAN/WAN connections were sparse.
Case Study #5: Point‐of‐Sale Stations at a Multi‐Site Retail Company
ABC Retail Company exists in more than 100 locations spread throughout outdoor malls in
the United States. A retail company that specializes in the sale of items as opposed to
services, multiple point‐of‐sale (POS) terminals were required in each store to complete
customer transactions.
Originally leveraging a mainframe application for the completion of such transactions, ABC
Retail was forced by obsolescence to upgrade its technology to a Windows‐based solution.
This Windows‐based solution enjoyed a much greater set of capabilities for tracking orders
and analyzing trends in purchases. It, however, also required a network and directory
services infrastructure in each individual store. Looking at the possibility of extending its
Windows Active Directory (AD) domain along with accompanying server infrastructures
out to each and every store, ABC Retail Company began looking for alternatives.
The Essentials Series: Important Questions in Implementing Virtual Desktops Greg Shields
15
Being a company in more than 100 locations, the idea of distributing server equipment to
each store represented an administrative nightmare. With so much distribution of
equipment, even the most simple of maintenance processes such as monthly patching
would be a painful process. ABC Retail Company needed a mechanism to centralize its
infrastructure rather than distribute it to support its new Windows application.
ABC Retail Company also settled on a virtual desktop infrastructure as its solution of
choice. Using zero clients as the mechanism for delivering the application’s user interface
(UI), the company was able to deploy very little hardware to its individual stores.
Improving the situation even more was the idea that zero clients could be replaced by nontechnical
retail managers when problems occur. If a problem occurred, the manager need
only ship the device back to the central IT organization. Replacements were kept on‐site in
each store, and reconnecting to the infrastructure and POS terminals involved little more
than plugging in and powering on a replacement device.
As a public retail establishment, ABC Retail Company also handles payment cards, which
means its infrastructure falls under both the Sarbanes‐Oxley Act as well as PCI compliance
regulations. It was easily able to fulfill the requirements of both compliance regulations
because it’s selected zero clients could connect to payment card peripherals as well as
encrypt payment card information as it crosses the wire back to the central office. Payment
card approvals were done within the virtual desktop and not in the local store, so any theft
of computing equipment could not expose the company to liability. Security of the
environment was maximized because all customer data was always stored in the central
data center. As a result, ABC Retail Company was able to expand its operations at will
without fear of data exposure or loss.
Virtual Desktops Expand Application Access to Everywhere
These are but examples of how virtual desktops can extend the reach of your network
infrastructure to virtually anywhere. Whether you’re a university looking for a very
extensible computer lab or a multinational corporation trying to expand into otherwise
impenetrable markets, a virtual desktop infrastructure can extend the business
applications on your LAN to where you need them most. Adding a deployment of zero
clients to that infrastructure ensures the highest return on your virtualization dollar, while
creating an infrastructure that easily scales to your business’ needs.

What’s GNU in Virtualization

Taking a new operating system for a spin is easier than ever before with virtualization software but when that software is free, it’s even better. There are virtualization choices for all tastes listed here. For those of you who prefer hypervisor-based virtualization, I urge you to try Xen or Proxmox. If you’re into high performance, container-based OpenVZ wins the prize. Red Hat’s enterprise-level virtualization solution, KVM, delivers incredible performance for a full virtualization solution. And, for you desktop-level virtualization converts, VirtualBox dishes out performance and a gaggle of high-end features.
All virtualization software in this week’s article is released under the GPL-specifically GPL version 2. Software released under the GPL is free. Free, under the GPL, means that you have the freedom to use, examine, change, redistribute and even sell the software as your own.

KVM

The Kernel Virtual Machine is a full virtual machine (VM) solution for Linux-based hosts. Using it, you can run Linux, Windows and other operating systems as guests without modification. KVM is “traditional” virtualization in that each VM receives its own set of virtual hardware (CPU, RAM, disk, NIC, video). As of Linux kernel version 2.6.20, KVM’s kernel component is included as part of the core Linux code.
KVM offers a low-overhead virtualization solution that only requires the kernel component, CPU(s) with Intel VT or AMD-V extensions enabled, a modified version of QEMU, a processor-specific module (kvm-intel.ko or kvm-amd.ko) and a kernel loadable module: kvm.ko.

Virtually GNU Choices

• VirtualBox
• Proxmox
• Xen
• KVM
• OpenVZ

OpenVZ

OpenVZ is container-based virtualization, which is analogous to BSD jails or chroot environments. Virtual containers are powerful and performance is native but the major drawback is that you’re limited to a shared kernel for all VMs. A shared kernel means that if you run Linux, your VMs will also all be Linux VMs because they share the single running Linux kernel. Container-based virtualization is easy to implement, easy to maintain and is the least expensive form of virtualization currently available.
You might ask, “Why are containers so great when you share a single kernel — why wouldn’t you just install a new service on the original server system?” The answer is isolation. Containers are secure chrooted environments that are secure and isolated from one another.
For example, if you want to run multiple copies or versions of the Apache web server on your system, consider using containers to separate the different versions from one another. Or, if you run a required service that has a history of security problems (Certain versions of BIND, for example); a container is the perfect isolated and secure solution.

ProxMox

Proxmox Virtual Environment (VE) is a clever combination of KVM and OpenVZ in one server. It serves the best of both worlds: Full virtual machines and container-based virtualization. In case you didn’t see it, I did a review article on Proxmox VE 1.2 back in May.

VirtualBox

VirtualBox is Sun’s (Now Oracle’s) entry into desktop-level virtualization’s fray. Now at version 3.0.10, VirtualBox competes favorably with Microsoft’s Virtual PC, VMware Workstation, Parallels Workstation and QEMU. Available for Windows, Linux, Mac OS X and Solaris hosts; VirtualBox brings you a rich desktop virtualization environment including such amenities as host/guest shared folders, USB, serial ports, sound, adjustable graphics memory and a snapshot feature.
Perhaps the winner of the cool feature of the day is the import and export appliance wizard. Create a virtual machine with your application in VirtualBox and then export it as an appliance. The results give you an open virtualization format (OVF) file descriptor and a VMDK (VMware) disk file. You can also import from OVF files. Yes, VirtualBox is all that and a bag of computer chips.

Xen

Always the last word in virtualization (Alphabetically, that is), Citrix-sponsored xen.org is the free software version of Citrix XenServer. You can download it, run it and use as many copies as you need without ever paying a penny to Citrix or anyone else. There are also several freemanagement applications available for handling multiple Xen hosts and their VMs.
Xen Note: Don’t confuse the fact that Citrix XenServer 5.5 is free of charge with xen.org’s Xen product, which is free software as defined by the GPL.
You also have the option of downloading a live Xen CD complete with four pre-configured virtual machines for testing. Download the Xen Live CD v2.0 and give it a try.
If you’re looking for real freedom with your choice of virtualization software, you have it. All levels. All types. All free. Write back and let me know how you like these options for your virtualization solutions.