To understand the need and usability of VDI, I'll start with an interesting
setup I saw in early 2006. This deployment had nothing to do with VDI as VDI as
a concept wasn't there. But they tried to get some functionality of VDI thorugh
an innovative, though not so recommended, deployment. The organization I am
talking about used to deal with animation and IP (Intellectual Property). To do
away with content theft or leakage, they thought of taking efficient security
measures which involved limiting users' access rights; not permitting USB
drives, Internet, and CDROMs, etc . Still, there was a probability that someone
could actually take out the hard drive or use some such mechanism to take out
data (like using a com port modem, etc). So, the IT team wanted to migrate all
the machines to the server room, so that they could apply security features of
the server room to the workstations. However, the biggest question was how to
give users access to their machines? They migrated all workstations to the
server room and laid down the KVM (Keyboard, Video and Mouse) cable across the
premises to connect them. This might sound funny, but it actually worked . The
benefit was, the users didn't have any physical access to the workstations, and
securing the workstations became easier as all were kept at a central
location.But certain loopholes remained. For example, KVM wires are not to be
used for such long distances and might cause deterioration in video quality and
latency in keyboard and mouse response. At the same time, even if the
workstations were kept in a single location logically, they required to manage
separate entities for the network independently, such as installing updates,
installing new apps, etc. The right solution for this is to have a setup where
all desktops can be hosted in the data center, and logically there would be a
single entity where you can just update a single image and take care of all
workstations for an entire group. At the same time, one can also stream sessions
on a network instead of doing it via KVM lines, and the user can access them
using a low cost, low power consuming hosts from their desktop. And this is what
Virtual Desktop Infrastructure is all about.
Types of VDI
The oldest form of VDI which we saw was Novel Net Ware remote boot servers,
which used to remote boot Windows 3.11 over the network from a Novel Net ware
server. This was followed by the not-so popular Remote Windows NT Remote Boot
Services, which was used for booting Win 3.11 and Win 95 remotely. At that time,
around 12 years back, we didn't call it VDI, even though the concept was more or
less similar-managing and virtualizing desktops from the data center (or what we
used to call it earlier: the server room).
Using Open VDI, you can stream any Windows and Linux applications to a virtual desktop. |
Open VDI also gives a very good reporting interface, where you can check the load and number of sessions running. |
For those who don't understand remote booting or disk-less booting, it's
basically booting a machine from the network without a hard drive. At the client
level, we used to have machines with drive but with full-fledged processors and
RAM, and the processing used to happen at the client level. So, you can't
exactly call it a VDI. In a true VDI setup, the processing should also happen
from the data-center. Then there were other similar offerings. A very famous one
from the open source world being LTSP. Some people treat it as a VDI, as VDI
isn't strictly defined yet. The other technology which helped in building the
VDI concept was the 'Terminal Services'. Here, the complete processing happens
at the server end, and the client only streams the KVM over the network. But
here the problem was, you could only stream Windows 2000 data from a Windows
2000 box. So, you needed separate machines for separate OSes and this feature
was only available on server class OSes. Technically there was no way to run
terminal services on desktop OSs and stream them to the thin client. Here, thin
clients are a bit different from clients for the remote boot services. Of
course, thedisk was missing, but at the same time it also had a low end
processor and some amount of RAM which could only boot the machine with its
embedded OS and start the client's terminal services. Few similar offerings such
as VNC, RDP, etc. were also there. However, these offerings were not able to
stream different OSes from the same terminal server, so people started hosting
different virtual machines on a single powerful server to run terminal services
on it. This added a lot of overhead to the servers, and since multiple virtual
machines were running the Terminal Services, the management became difficult.
This is where true VDI solutions came into picture. These solutions mainly
encompass most of the above mentioned technologies such as Terminal Services,
Thin Clients, Virtualization, but are specialized to provide a VDI . Here, we
look at one such solution, and in subsequent months shall discuss more.
Once you select Publication wizard, you will be able to see all applications, both in Windows and Linux servers. |
Open Virtual Desktop
This virtual desktop has some really useful features as compared to other
similar products. The first is the ability to stream both Windows and Linux
applications on the client desktop simultaneously. The other is the
comprehensive management interface. We talk about all this and show how you can
install it.
Installing Open Virtual Desktop
We have provided the ISO in the PCQ Xtreme DVD with this issue. Alternately,
you can download the installation ISO from http:// tinyurl.com/nafdv5. It's not
a huge file and so would not take much time to download. Once done, you can burn
the ISO on a DVD and boot your system using it. The installation is similar to a
standard Ubuntu install and there is nothing much to do. At the beginning of the
installation, it offers three choices. Select the first, which says, 'Install
Ulteo SM and ApS and press Enter.' This shall install all components of Open
Virtual Desktop (OVD) to your server. We recommend you use a server with at
least 2GB RAM and one of the latest multi-core processors. Once the installation
is over, check if the machine has got an IP from your DHCP or not. Next, go to
one of the other machines on the same network and open http://ip_address_of_OVD_
Server/ session manager/ admin. You shall be asked for a user name and password.
Type admin for both and you should be logged into the admin panel of OVD. Now,
register your server here and make it the production server so that you can
start hosting desktop sessions on it. For this, go to Servers Menu -->
Unregistered Servers. Here, you should be able to see your server. Click on
register and the server will disappear from this menu, and would be visible
within the Server menu. Now click on 'Switch to production' option and the
server shall be available to host sessions.You can go to http://ip_address_of_OVD_Server/sessionmanager
and be able see some test users to login through. To create your own
users, go to Configurations --> Profile Settings and select "I want to create my
own users" radio button. Now go to the users menu and you should see the option
to create new users. Here, just keep filling the user name, login name and
password for users and you should be able to create as many users as possible.
Once this is done, the next thing you have to do is assign applications to
users. This will make sure the users/groups can only use the applications they
are authorized to.The easiest way to do this would be to create new application
groups and align them with users which you have created. For this, go to
Applications-> Publications Wizard. Here select the 'Create a group with users'
radio button and you will see the list of users which you have just created.
From here, select users who would have similar rights, or in other words will be
in a single group, and hit Next. It will then ask you to give a name to the user
group. Once done, it will ask you to either select an application group or to
create a new application group. Please note that this is a newly installed
machine and so you will not have any pre-created application group. Create a new
application group by selecting the first option which says, 'Create a group with
applications.' Once you select this radio button, you will see all available
applications on the system. Select apps which you want to allow for the current
user group and press Next. In the next screen, it will ask you to give a name to
the application group. Give an appropriate name and proceed. In the next screen
it will ask you to confirm the activity. Now you can go to any machine in the
same network and access http://ip_address_ of_OVD_Server/sessionmanager. Here
you shall see a list of all users that you have created. Select the user you
want to log into the network with and type its password.
Now you should be able to see a nice desktop with applications which you have
authorized to this user.
Getting the Windows touch
As you have installed everything on a Linux box you should be seeing only
Linux-based applications. However, you can get Windows apps directly on the same
virtual desktop session along with Linux apps. Sounds exiting? Let's see how you
can do it. All you have to do is to get a machine with Windows XP/200x
installed, and applications which you want to distribute across the OVD should
also be there. Now you have to download a client of OVD for Windows. You can get
it from http://water2. ulteo.com /ovd/releases/windows/ovd-agent-latest.exe.
Once it has been downloaded, you can install it by clicking on the setup file.
The only thing you have to do in this setup wizard is to give the IP address or
FQDN of the machine where you have installed the setup file, and the session
manager address of the OVD server, which is http://ip_address_of_OVD_Server/sessionmanager.
Now follow the wizard till it ends and after that you should be able to see the
Windows machine in the http:// ip_address_of_OVD_Server/sessionmanager/admin
pages/ Servers --> Unregistered Servers section. Now register and make the
machine production server, in exactly the same way as you did for the main OVD
server (explained earlier). Once that's done, while creating application groups
or while running Publication wizard, you should be able to see applications
installed on the Windows machine as well, and you should even be able to push
these apps directly to the user sessions.