Dhaval Mtmuito Report

8/12/2019 Dhaval Mtmuito Report

1/50

DeskVirt : Low Cost Computing UsingVirtualization For Remote Desktop

Submitted in partial fulfillment of the requirements

for the degree of

Master of Technology

by

Manvar Dhaval R.

Roll No: 10305021

under the guidance of

Prof. Anirudha Sahoo

Department of Computer Science and Engineering

Indian Institute of Technology, Bombay

2012


2/50

Dissertation Approval Certificate

Department of Computer Science and Engineering

Indian Institute of Technology, Bombay

The dissertation entitled DeskVirt : Low Cost Computing Using Virtualization For

Remote Desktop, submitted by Dhaval Manvar Rameshbhai (Roll No: 10305021) is

approved for the degree ofMaster of Technologyin Computer Science and Engineering

from Indian Institute of Technology, Bombay.

Prof. Anirudha Sahoo

CSE Dept., IIT Bombay

Supervisor

Prof. Varsha Apte


Internal Examiner

Prof. P. Kulkarni


Aditional Internal Examiner

Prof. Tom Mathews

Civil Dept., IIT Bombay

Chairperson

Place: IIT Bombay, Mumbai

Date: 2012

i


3/50

Declaration

I, Dhaval Manvar, declare that this written submission represents my ideas in my own words

and where others ideas or words have been included, I have adequately cited and referenced

the original sources. I also declare that I have adhered to all principles of academic honesty

and integrity and have not misrepresented or fabricated or falsified any idea/data/fact/source

in my submission. I understand that any violation of the above will be cause for disciplinary

action by the Institute and can also evoke penal action from the sources which have thus not

been properly cited or from whom proper permission has not been taken when needed.

Signature

Name Of student

Roll number

Date

ii


4/50

Acknowledgements

I would like to take this opportunity to sincerely thank my advisor Prof. Anirudha Sahoo. My

advisor has given me constant support and guidance throughout my M. Tech. project. I havedeveloped technical abilities in terms of thinking as well as expressing my thoughts while doing

technical writing under his guidance.

I would like to thank my colleague, Mr. Mayank Mishra (Ph.D. Student, CSE Department,

IIT Bombay) for his guidance and active involvement in discussions of the project. I would

like to thank my friend and classmate Jeet Patani for his constant support and motivation

during my stay in IIT Bombay. I would also like to acknowledge Mr. Punit Rathod (Ph.D.

Student, CSE Department, IIT Bombay) and Mr. Sampreet Sharma (M. Tech. Student, CSE

Department, IIT Bombay) for giving their valuable feedback towards the improvement of thisthesis.


5/50

Abstract

A major chunk of investment in enterprises goes for computing hardware (e.g. computers,

server machines, etc.) which are used in data center as well as by employees. With increase in

the complexity of software, more computing power is required for their execution. This increase

in execution power is achieved by replacing old machines with high capacity ones. The cost of

this process is high and is also cumbersome and time consuming task. To reduce maintenance

cost and time, remote desktops are being used. In remote desktop mechanism, a thin client

or an old PC (Personal Computer) can be used as a workstation. The actual computationhappens on the remote server and workstation is only used to access the remotely executing

desktop. Thin client is a very low hardware configuration dumb terminal and cheaper than

the normal PC. In existing solutions of remote desktop, only one instance of operating system

runs on remote server and multiple users simultaneously log in using workstation. But problem

happens when one of the users misbehaves (e.g. causes the system to crash), which may result

in denial of service for other users. Another problem being a few active users connected to

multiple physical machines (PM), and the PMs are underutilized. The main reason for this

problem is the lack of facilities like migration and consolidation. All these problems result in

inefficient PM resource utilization. These problems can be addressed by using virtualizationtechnology to provide remote virtual desktop to the users. With this scheme, users desktop

runs as Virtual Machine (VM) on a remote server, i.e. PM. As a result of this scheme, users

get a personalized virtual desktop, which makes their session safe from the malicious activities

of other users. The use of virtualization improves the overall resource utilization because of

the facilities like dynamic resources provisioning, live migration, capability of consolidation

and load-balancing. DeskVirt aims to provide open source solution for remote desktop by

making use of virtualization technology and using existing open source software. The results

of experiments on DeskVirt ensure that end users get approximately same experience as they

work on traditional standalone PC. Since the solution is based on open source, it is possiblefor us to implement different VM migration and PM consolidation algorithms to improve the

performance of the system.


6/50

Contents

1 Introduction 1

2 Related Technologies 5

3 Problem Formulation 7

4 Contributions In Development Of DeskVirt 8

5 DeskVirt Architecture 10

5.1 Central Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2 Local Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.3 Virtualization Aware Physical Machine (VAPM) . . . . . . . . . . . . . . . . . . 12

5.4 NFS (Network File System) Server[9]. . . . . . . . . . . . . . . . . . . . . . . . 135.5 Users Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6 DeskVirt Access Scenarios 15

6.1 Desktop Access Within LAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.2 Desktop Access Over Internet (WAN) . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Deployment And Experiments 21

7.1 Experiment 1: Start Up Time of DeskVirt In LAN Scenario . . . . . . . . . . . 22

7.2 Experiment 2: Applications Performance Running On DeskVirt . . . . . . . . . 24

8 Conclusions And Future Work 27

Appendices 32

A Hardware Configuration of Servers Used For DeskVirt Deployment 32

B Central Management Server Software Installation 33

C Sofware Installation On NFS Server 34

i


7/50

D Software Installation On VAPM Server 36

E Software Installation On Local Management Server 37

F Software Installation On Virtual Machine 38

G Modification In initrd File System (initrd.img) 40

ii


8/50

List of Figures

5.1 DeskVirt Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.2 Functional Diagram (DeskVirt Core Components And Required software On

Them).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6.1 Deskvirt Components Involved To Access Desktop In LAN Scenario . . . . . . . 16

6.2 Message Passing In LAN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.3 Deskvirt Components Involved To Access Desktop In WAN Scenario. . . . . . . 19

6.4 Message Passing Diagram In WAN Scenario . . . . . . . . . . . . . . . . . . . . 20

7.1 Experimental Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.2 Virtual Desktop Start Up Time Results . . . . . . . . . . . . . . . . . . . . . . . 23

iii


9/50

List of Tables

1.1 Comparison of Remote Desktop Software . . . . . . . . . . . . . . . . . . . . . . 3

7.1 Configuration of Virtual Desktop (VD) And Results of SunSpider Benchmark. . 25

7.2 Configuration of Virtual Desktop (VD) And Results of SunSpider Benchmark. . 25

7.3 Configuration of Virtual Desktop (VD) And Results of Linux Kernel Compilation 25

7.4 Configuration of Virtual Desktop (VD) And Results of Linux Kernel Compilation 26

iv


10/50

Chapter 1

Introduction

The complexity of software and their demand of computing power is an ever increasing phe-

nomenon. This results in a very rapid increase in the computational power and capacity of

the hardware. Even the desktops or laptops which are used by the users now-a-days have a

heavy capacity hardware which, most of the times, is much more than required. This results

in unnecessary wastage of resources and in turn increases the over all cost. Even these high

capacity machines become out dated very soon and are required to be replaced with newer high

capacity machines.

This replacement of machines puts a very high burden in terms of cost, effort and time.

Such upgrades require extensive planning. One solution to reduce the cost and resources re-

quired by individual user is to provide them with the facility of remote desktop. Users no longer

use a powerful, more-than-required hardware but share a remote powerful machine using light

weight thin clients[16]. These thin clients may not necessarily be a totally different hardware

but can also be in the form of old PCs. The configuration required for thin client is very low

as they run stripped down version of Linux kernel. This results in extensive saving in cost

and time required for maintenance and upgrades. Some open source solutions are available for

remote desktop, like LTSP (Linux Terminal Server Project)[5], Openthinclient[10], etc. These

software need PXE (Pre eXecute Environment) [11] enabled Ethernet card to boot thin kernel

via Ethernet. Openthinclient has been developed in Java which needs JVM to execute while

LTSP is developed in shell script.

In current remote desktop solutions, there is one instance of the operating system running

over a powerful remote server which supports multiple users logged in to it remotely. There are

many obvious problems in this scenario. For instance,

1. Inherent sharing of the OS instance among multiple users. One user can cause others to

suffer. E.g., a misbehaving application executed by one user can consume most of the

resources on the system leaving no free resources for other users. Thus the performance

experienced by other users greatly suffers.

2. Imbalance in loads of different remote servers. One server may be heavily loaded because

of multiple users logged in, whereas a different server is lightly loaded due to very few

1


11/50

users logged in. There are no load balancing/consolidation schemes available in such

solutions.

Capability of live migration[22]available with virtual machines using virtualization technolo-

gies (like Xen[21], KVM[23], VMware ESX[19], etc.) has made it possible to dynamically load

balance and consolidate[24]the server loads. The same capability can be used in providing anefficient remote desktop service to the users. Every user can own a personalized remote virtual

machine which is executing on a remote server and being accessed by a thin client. Thus, the

user gets the experience of a desktop and a personal machine which is as good as a local desktop.

Sometimes users may need to access their desktop from outside local network, i.e. access

over Internet. For example, user wants to access remote desktop from Internet cafe as they

may not have personal computer. In this case, user is not allowed to install any software on

PC in Internet Cafe. As web browser is available on almost all PCs or laptops, we can provide

remote desktop using web application. There are many solutions, both web browser based andstandalone, available for remote desktop over Internet, e.g. VNC[18] (Virtual Network Com-

puting), RedHat SPICE[12] (Simple Protocol for Independent Computing Environments) etc.

RedHat SPICE protocol is better choice for remote desktop over Internet because it supports

local device access and audio from remote desktop. But there is no web browser based solution

available for RedHat SPICE. Thus, to access remote desktop using RedHat SPICE, user has

to install client side software on the local machine. VNC (Virtual Network Computing) can be

used to access and control remote desktop over Internet using web browser. But it has limited

functionalities. For instance, VNC only transfer video but it cannot transfer audio, user cannot

use local external devices (like USB flash drive), etc. Moreover, VNC is not safe (for securitypurpose) to use over Internet. Table1.1shows the different features of remote desktop software.

In this project, we have presented a scheme to provide remote virtual desktops to users over

LAN and over Internet. Although, there are some proprietary products already available in the

market. We believe that our scheme will be much more cost effective and easily deployable by

small enterprises and educational institutes. Our project is open source and hence can serve as

a platform for future improvements and development. In this project, Xen hypervisor is used

to provide virtualization environment and LTSP (Linux Terminal Server Project) to access

remote desktop. As users can access their desktops from any thin client in the local network,we have to map users to their corresponding desktops, i.e. VMs, on the fly. To make this

possible, we have made some changes in LTSP software and have added scripts which are used

for user-to-VM mapping. For this project, we have used tightVNC[17]( an open source version

of VNC) for remote desktop access over Internet. The client software is available in form of

Java Applet which can be used over web browser. We have implemented a very small set up

by integrating Xen hypervisor and LTSP software.

This project is aimed to provide following basic facilities of remote virtual desktop.

To provide open source solution for remote desktop virtualization so that it can be usedby small enterprises and educational institutes.

Easy to deploy and low level administrator maintenance.

2


12/50

Table 1.1: Comparison of Remote Desktop Software

Open

ThinClient

LTSP VNC RedHat

SPICE

Open Source(Source code

is available, there easy to

modify as per requirements.)

Yes Yes Yes Yes

Developed In (Software

developed in Java is heavy

to execute than pure Shell

Script or C language)

Java Shell Script C++/Java C/C++

USB Support At Client

(User can use USB attached

device from client side.)

Yes Yes No Yes

Audio Support At Client

(User can get Audio from

server.)

Yes Yes No Yes

Allows Local execution

of Application (User can

execute specific applications

on thin client locally.)

Yes Yes No Yes

GUI Export (How does

server export desktops dis-

play to client?)

SSH -X XDMCP (X

Display Man-

ager Control

Protocol) or

SSH -X

RFB

(Remote

Frame-

Buffer)

SPICE

Protocol

Client side software Not Re-

quired

Not Required Required

(VNC

client)

Required

(SPICE

client)

Does web browser basedsolution available?

No No Yes No

Thin client based solu-

tion?

Yes Yes No No

The global accessibility of virtual desktop.

We have assumed that user does not use high definition graphics applications, for instance,

Video Games. The current stage of this project doesnt solve the security issues which basicallyexist in remote desktop solutions over Internet. The main part of this project is its architecture.

Under this architecture, we can use any open source software for different functionalities. For

3


13/50

instance, we have used Xen hypervisor to provide virtualization environment but it is not the

hard requirement. We can also use KVM hypervisor instead of Xen with small changes in the

developed scripts. Similarly, we can use RedHat SPICE protocol instead of tightVNC.

The rest of the report is organized in the following manner. Chapter 2 discusses the exiting

technologies. In Chapter 3 we discuss the Problem Formulation in detail. Chapter 4 describes

the contributions of this thesis. We discuss the architecture and core components of our solution,

DeskVirt, in Chapter 5. Chapter 6 discusses communications among different components of the

system when a user accesses the remote virtual desktop. Chapter 7 describes the deployment

strategies of DeskVirt and the experimental evaluation of DeskVirt. We discuss conclusions

and future work in Chapter 8.

4


14/50

Chapter 2

Related Technologies

Following two technologies provide the low cost computing using remote desktop virtualization.

These both are proprietary products.

1. VMWare View[20]:

VMWare has a remote virtual desktop solution, named as VMWare View. The aim of

VMWare View is to provide a desktop environment to user without having real desk-

top hardware. The actual computation or execution of application happens at remote

place and users can access the desktop from anywhere. VMWare View has following

components.

VMWare ESX/ESXi server: VMWare ESX is an enterprise-level computer vir-

tualization product offered by VMWare. It runs on host Operating System as asoftware. More than one different Operating Systems can run over it in form of

virtual machines.

vCenter Server: This service acts as a central administrator for VMWare ESX/ESXi

servers that are connected on a network. vCenter Server, formerly called VMWare

VirtualCenter, provides the central point for configuring, provisioning, and managing

virtual machines in the data center.

View Client Software: This software runs on users PC or thin client. It is used to

access users desktop running over remote server (as virtual machine). This software

is currently supported on Microsoft Windows OS.

View Connection Server: View Client software first connects to View Connection

Server software for user authentication by using Window Active Directory. After

authentication, it redirects request to appropriate VM running over ESX server.

Connection server supports only Windows Server 2003 Operating System.

View Administrator: This Web-based application allows administrators to con-

figure View Connection Server, deploy and manage View desktops, control user

authentication and troubleshoot end user issues.

VMWare View uses Microsoft RDP (Remote Desktop Protocol) for Window OS and

PCoIP (PC-over-IP) as display protocols for Linux OS. As VMWare View is proprietary

5


15/50

product, its deployment cost is high. Thus, most of the schools, colleges or universities

cannot easily afford this solution.User can use thin client to access remote desktop, but

thin client needs an OS to execute View Client Software. This facility is available in some

high configuration thin clients only.

2. Citrix XenDesktop[1]:XenDesktop is another remote desktop virtualization solution. It delivers Microsoft Win-

dows XP or Vista virtual desktops as a remotely available service to users. The core

components of XenDesktop are:

Citrix XenServer: XenServer is used to create and run multiple virtual ma-

chines on the physical machine. It uses Xen hypervisor to provide virtualization

environment.

Desktop Delivery Controller: This software is installed on servers in the data

center. It authenticates users, manages users virtual desktop environments andestablishes connections between users and their virtual desktops. It controls the state

of the desktops, starting and stopping them based on demand and administrative

configuration.

Virtual Desktop Provisioning: It provisions server, creates and manages virtual

desktops from a single desktop image on demand. It also optimizes storage utilization

and provides a virtual desktop to each user every time they log on.

Virtual Desktop Agent: This software is installed on virtual desktops. It enables

direct ICA (Independent Computing Architecture) connections between the virtualdesktop and users endpoint devices.

Desktop Receiver: It is installed on users endpoint devices(thin client or PC).

It enables direct ICA connections from endpoint devices to virtual desktops.

Using XenDesktop, users can access their desktop from anywhere and anytime where

Internet access is available. But, as it is a proprietary product, like VMWare View, de-

ployment of XenDesktop is not affordable by small enterprises. It only supports Windows

OSes as Desktop. End users device is required to have capability of running Desktop

Receiver software. Moreover, it cannot be used on thin clients without local disk.

6


16/50

Chapter 3

Problem Formulation

Remote desktop is the way to provide low cost computing over network. Thin client or low

capacity PC can be used as workstation. Users desktop operating system runs on remote

server. Thin client based workstation, i.e. dumb terminal without local storage, is booted

by downloading stripped down version of kernel from server over LAN. In this kind of remote

desktop, only one instance of operating system (OS) runs on the remote server and multiple

clients can concurrently log in. If OS crashes due to one user, all other users are affected.

Moreover, without consolidation and load-balancing of user desktop session, this scheme tends

to waste a lot of resources when there are fewer number of users in the system.

To get rid of the above problems, virtualization can be used at server side. Every user is

provided with an individual VM (Virtual Machine). Thus, every user gets a personalized desk-

top. By leveraging the facilities provided by virtualization like dynamic resources provisioning

and live migration, servers resources can be utilized efficiently. There are some proprietary

products already available in the market, e.g. VMware View, Citrix XenDesktop, etc, as dis-

cussed in Chapter 2. Due to the cost involved, these products would have scope of deployment

mostly in large enterprises. Moreover, these products need computer system with local storage,

Operating System and client side software to access remote desktop. Because of this reason,

we cannot use these software for thin client based solution.

The aim of this project is to provide an open source solution for low cost computing using

desktop virtualization which can be used by small enterprises and educational institutions.

Because, DeskVirt is open source, it is free of cost and it is also easy to maintain and deploy.

DeskVirt uses existing open source components available for accessing remote desktop. The

management of virtual machines, supporting users desktop, can be achieved by using some

already existing mechanisms, e.g. sandpiper[24]. DeskVirt can also be used as platform to

check the effectiveness of various VM placement and load-balancing algorithms.

7


17/50

Chapter 4

Contributions In Development Of

DeskVirt

This section gives overview of the work done in last one year on DeskVirt in terms of my MTP

stage-I and stage-II.

1. Work Done During MTP Stage-I:

Following work has been completed for this project in MTP Stage-I.

Analyzed existing open source remote desktop virtualization techniques.

Analyzed different remote desktop accessing techniques and selected LTSP (Linux

Terminal Server Project) because it is an open source and easy to deploy.

Made changes in LTSP source code to make it usable for this project.

Designed and deployed a small set-up consisting of components like

Xen virtual machines

LTSP server on virtual machines

Management server to manage user authentication and creation of virtual ma-

chines, etc.

Developed daemons which are used for information communication among different

components of the architecture.

At the end of Stage-I, thin client based solution was completed with some issues. For

instance, users workstation was downloading kernel twice for users workstation to VM

mapping. Due to this, the overall delay to get remote desktop was very high. We assumed

that each user will have at most one operating system. But in real life, user can have

more than one operating systems.

2. Work Done During MTP Stage-II: Following work has been completed for this

project in MTP Stage-II.

Addressed the problems faced in Stage-I, e.g. users workstation downloading Linux

kernel twice, single operating system per user, etc.

8


18/50

Modified existing architecture to include web based solution and made it more ro-

bust.

Developed web application for remote desktop over Internet. For web application,

PHP server side scripting language has been used. To store users desktops infor-

mation, My-SQL database system has been used. Modified existing daemons and developed new daemons to support modified DeskVirt

architecture.

Designed and deployed a small set-up for modified DeskVirt architecture.

Conducted experiments on DeskVirt to compare the user experience with standalone

PC and different configurations of virtual desktop. These experiments include the

start up time of DeskVirt and the performance of the applications on virtual desktop.

9


19/50

Chapter 5

DeskVirt Architecture

Figure-5.1shows the high level architecture and various components involved in DeskVirt.

Figure 5.1: DeskVirt Architecture

This architecture is neither fully centralized nor fully distributed. The most of the infor-

mation required to access users desktop are available on central management server. The

various functionalities of DeskVirt are distributed among different components which makes

them localized to a particular network, i.e. LAN. Figure-5.2depicts the functional diagram of

the DeskVirt system. DeskVirts components are shown in boxes and software run on them

are shown in circles. The line with arrow shows the flow of the control messages and data

exchange among the components. The software shown in green circles are developed programsfor DeskVirt and the daemons shown in the pink circles are off-the-self open source software.

10


20/50

Figure 5.2: Functional Diagram (DeskVirt Core Components And Required software On Them).

The functionalities of the following components of DeskVirt and software running on them

are given in the following sections.

1. Central Management Server

2. Local Management Server

3. Virtualization Aware Physical Machine (VAPM)

4. NFS (Network File System) Server

5. Users Workstation

5.1 Central Management Server

The central management server is a multi-purpose server in this architecture. The central man-

agement server is the only component of the system which is directly connected to the Internet,

so it works as firewall and proxy server. It is the central entity of DeskVirt from where other

components can get the required information. It contains database of users and their desktops.MySql database management system is used in this project. It also runs the web application

which is required to access the desktop over Internet. This web application has been developed

11


21/50

in PHP server side scripting language which needs apache web server to execute. Using web

application, user can control remote desktop, create new desktop and modify it (e.g. number

of CPU, increase the memory and disk space). This web application uses shell script to send

request, to create, to modify and to delete the virtual desktop, to the daemon running on NFS

server.

5.2 Local Management Server

This server works as a management server for a particular LAN. It contains the stripped down

version of Linux kernel which will be downloaded by diskless workstations at start up time.

The users workstation (thin client or old PC) always first contacts to local management server

available within its LAN to get the initial information. This server runs the following software.

1. DHCP (Dynamic Host Control Protocol) server [3]: DHCP server is used to

assign IP address to the users workstation. It also gives the IP address of the system

from where the users diskless workstation can get the required Linux kernel which is used

to boots it up.

2. TFTP (Trivial File Transfer Protocol) server [15]: Users diskless workstation

uses TFTP protocol to access the Linux kernel from management server. Thus, TFTP

server software should be installed on every local management server.

3. DeskVirt Management Daemon (DMD) : The main task of this daemon is to mapusers to their appropriate desktops. When user starts workstation, it first asks for users

credential, i.e. use name and password. Once DMD has identified the user, it then maps

users workstation to his/her appropriate desktop.

4. Resource Provisioning Daemon (RPD) : This daemon is used to provision resources

(e.g. CPU, Memory, etc.) to the users desktops (VMs) dynamically based on their

requirements. It also reports the central management server about the changes it has

made for desktop.

5.3 Virtualization Aware Physical Machine (VAPM)

This is a high configuration PM (Physical Machine) where hypervisior (e.g Xen, KVM) runs.

The users desktop runs on this PM. This PM mounts users desktop disk image from NFS

server. The following daemons run on every VAPM to automatically manage users desktops

(VMs). To provide virtualization environment, the hypervisor (e.g. XEN or KVM) is required.

DeskVirt has been tested with both XEN and KVM hypervisor. The following description is

given only for XEN hypervisor.

1. Xen Hypervisor [21] : Xen is a free and open source hypervisor which provides virtu-

alization environment. It runs on bare hardware in the highest privileged level. Multiple

12


22/50

virtual machines(Domains) can run on Xen. Xen provides isolation among running do-

mains and also provision resources as per the given configuration of individual domain.

Xen uses para-virtualization approach which reduces the overhead due to virtualization

layer exist between physical hardware and OS running as a domain.

2. DeskVirt VAPM Daemon (DVD): This daemon uses port 5000 to listen for requestsfrom DMD. The main task of this daemon is to start users desktop (VM) on request and

reply the status of the newly started VM. Status would be whether VM has started

successfully or not.

3. Virtual Machine (Users Desktop) : Users Desktop runs as a Virtual Machine(VM),

or Domain in Xen, on VAPM server. LTSP (Linux Terminal Server Project) server

application runs on each VM. Informally, it is a server-cum-desktop kind of Linux where

both desktop as well as server applications can run. The User Session Status daemon keeps

track of the status of the logged in users session. The functionality and requirement ofthis daemon is described in next section.

4. LTSP(Linux Terminal Server Project) Server [7] : Linux Terminal Server Project

(LTSP) is an open source software for Linux operating system. This software is installed

on users desktop, i.e. VM. It allows more than one users to simultaneously use the same

operating system running on the remote server. In our project, we are using it for remote

access by single user because we have one virtual machine per user. Users can use low

capacity thin client or old configured PC as workstation. Thin client boots kernel with

the help of PXE(Preboot Execution Environment) enabled network card. Thin client

does not require any storage disk to book kernel . LTSP uses standard protocols like

DHCP(Dynamic Host Configuration Protocol), TFTP(Trivial File Transfer Protocol),

etc., to boot up thin client. LTSP server software runs as an application on remote

server. By default, LTSP uses X11-over-ssh for connection and communication between

thin client and LTSP sever application. Client downloads stripped down version of Linux

kernel and initrd(small filesystem image file) from remote server using TFTP protocol at

boot time. As kernel loads, it initializes clients peripherals and loads proper drivers. At

the end of this booting process, client runs LDM(LTSP Display Manager) screen script.

LDM displays default login screen to the user. Once user enters user-name and password,

LDM creates an SSH tunnel between client and LTSP server. LDM is written in shell

script, so we can easily modify script as per requirements. Upon entering correct user

credentials, client displays desktop GUI which seems to be same as client machine booted

from its local disk.

5.4 NFS (Network File System) Server [9]

The NFS server stores the disk images of users virtual desktop. The number of NFS server

might be more than one depending on the number of desktops. When user creates new desktop,the web application will first choose one of the available NFS servers based on the available disk

space. On the NFS server, two daemons run, named as VMGenerator and DesktopGenerator.

13


23/50

VMGenerator continuously generates a pool of the VM disk images and DesktopGenerator

listens for the request to generate new desktop for user. When DesktopGenerator receives

request to create new desktop from central management server, it takes a VM disk image from

the available pool and makes required changes in the disk image as per the users requirement.

The place of NFS server can be changed as per the requirements. For instance, if the number

of desktops to be supported is less, the central management server can work as NFS server.

If the NFS server and VAPM server are available in the same LAN, the performance of the

user desktop will increase. Thus, to speed up the desktop performance, there should be an

individual NFS server for each LAN.

5.5 Users Workstation

Users can access their desktops within internal LAN or over Internet, i.e. Wide Area Network

(WAN). To access desktop from withing LAN, user can use thin client. Thin client is a dumbterminal which has low capacity CPU (e.g. 512 MHz processor), less amount of memory (e.g.

256 MB) and no local disk. It should have PXE (Preboot Execution Environment) enabled NIC

(Network Interface Card). This NIC is used to make DHCP query on start up and to download

Linux Kernel from local management server. Users can also use their old configuration PCs

with local disk instead of thin client. In this case, the local disk is used to store the stripped

down Linux kernel which is otherwise downloaded from the management server. Thus, the local

disk saves the time to download Linux kernel. Based on from where user is accessing desktop,

users workstation needs different types of software.

1. Desktop Over LAN : User can access desktop using diskless thin client or old con-

figuration PCs with local disk. Users workstation runs very stripped down version of

the Linux kernel. To map users workstation to appropriate users remote desktop, the

daemon running on management server needs users information, i.e. user name and pass-

word. To get these information, when Linux kernel loads on users workstation, it first

loads a program (named as DeskVirtd) which asks for users credential. This program

sends users information to local management server which will map the workstation to

appropriate desktop.

2. Desktop Over WAN : The web application, developed in PHP, is used to access desktopover WAN. The web application loads Java applet VNC viewer for remote desktop. Thus,

to access remote desktop at client side, user needs to install Java plug-in on the web

browser.

The next section describes the step by step procedure to connect users workstation to remote

virtual desktop.

14


24/50

Chapter 6

DeskVirt Access Scenarios

When user starts the workstation, there are many message exchanges between workstation

and local management server. In this section, we shall look at how different machines, i.e.

workstation, management server, VM, interact with each other by passing messages.

6.1 Desktop Access Within LAN

DeskVirt is aimed to provide low cost systems for the computer laboratory in schools, small

colleges, universities or small industries where most of the time users work withing labs or

offices. Using thin client (diskless, low processing and memory machine), user can access

remote virtual desktop. We can also use old configuration PCs for re-usage purpose to access

desktop. The diskless workstation needs to download strip down version of Linux kernel to bootup and initialize the local hardware. The workstation with local disk do not need to download

this Linux kernel as we can store it locally. Figure6.1depicts the enlarged view of LAN part

shown in figure5.1.

The architecture shown in Figure 6.1 is required to reduce the load on the central man-

agement server. Local management server gets the information of all the users from central

management server. Thus, users can access their desktop from any LAN in the internal network.

During the start up of users workstation, there are many message exchanges among different

servers and users workstation. Figure6.2shows these messages and their relative timing withrespective to the start up of workstation.

Two different colors in Figure6.2shows two activities during the boot up of workstation.

The light gray part depicts user workstation to remote virtual desktop, i.e. VM, mapping. The

DeskVirt access time (or start up time) is divided into three parts (named as tc startup time,

user-to-VM mapping time and ltsp start up time). Chapter 7 disscusses about DeskVirt start

up time in more details. The light green part of the Figure 6.2 shows the mounting of required

file system from VM to workstation and the establishment of user session. The steps to access

desktop within LAN shown in Figure6.2are listed below in detail.

1. When user starts workstation, it first sends request to DHCP server using PXE enabledEthernet card. As per the architecture, DHCP server is running on the local management

server, thus it gets DHCP request.

15


25/50

Figure 6.1: Deskvirt Components Involved To Access Desktop In LAN Scenario

2. Local management server sends IP address for the workstation. It also sends own IP

address as TFTP server to download Linux kernel.

3. Users workstation then downloads the kernel and initrd[2] (compressed file system con-

tains scripts and other configuration files which are used at boot time of the system) from

management server. If workstation has local hard disk, Linux kernel and other required

files will be stored locally and thus in this case, workstation doesnt require to download

kernel. When kernel boots up, DeskVirtd daemon, included in initrd file system, requests

username and password. This step is required for correct mapping of users workstation

to his/her desktop.

4. Workstation sends users credentials and its IP address to DMD daemon running on local

management server and waits for response.

5. In local management server, DMD daemon finds desktops corresponding to the user from

MySql database. It then sends users desktops information (e.g. name of desktop, Op-

erating System, etc.) to workstation.

6. DeskVirtd daemon, running on users workstation, displays the desktops information like

linux grub menu. User then selects one of the displayed desktop and sends it back to the

management server.

7. The DMD daemon then sends request to start users desktop to one of the running VAPMserver or starts new VAPM server based on the load on running servers. The DVD dae-

mon, running on VAPM servers host operating system (e.g. Domain-0 in Xen), gets the

16


26/50

Figure 6.2: Message Passing In LAN Scenario

request to start virtual desktop, i.e. VM. It starts the desktop and sends acknowledgement

back to DMD daemon.

8. On receiving ACK, DMD daemon makes required changes on database system to keep

track of the users desktop status. It then sends the IP address of the users virtual

desktop, i.e. VM, to workstation.

9. The daemon running on workstation gets the desktops IP address. It gives this IP

address to LTSP client script which will then mount the required filesystem from the

remote desktop.

10. On successfully mounting of the file system, LTSP client scripts start LDM (LTSP Display

Manager) which will display the log in screen. This log in procedure is required to create

a user session with remote desktop.

11. LTSP client software contacts LTSP server software running on desktop and sends users

credential. On successful log in, LTSP server starts new session and sends desktop output

to thin client.

Once the above procedure is done, user can work on remote desktop like local PC. User canuse local devices like USB flash drive, local printer, etc. User Session Status daemon, which is

running on users virtual desktop, keeps track of the status of users session, i.e. user is logged

17


27/50

in or logged out or shut down the desktop. Whenever user clicks shutdown button, it will

send shutdown message to management server. On receiving shutdown message, the manage-

ment server makes required changes in database. When user logs out from the remote virtual

desktop, it should run at low configuration. Whenever user clicks log out button, it sends log

out message to management server. On receiving log out message, the management server

makes required changes in database and sends the log out message to the daemon running on

VAPM to reduce the resource configuration, i.e. number of VCPU and memory. When user

logs in, User Session Status daemon will find the new user session and send resume command

to the management server. Management server then makes changes in database and send log in

message, which includes the resource configuration of the user virtual desktop, to the VAPM.

VAPM then provisions resources to the users virtual desktop according to the received log in

message.

LTSP software is made to run on non-virtualized environment. It uses ssh-tunneling[13] for

data communication between users workstation and remote desktop. So, if user moves mouse

or presses key on keyboard, the client software running on workstation will send these informa-

tion through ssh tunnel. It needs high computation capacity to encrypt and to decrypt these

messages over ssh. Thus, users desktop hangs up even when no high computation process is

running on server, i.e. remote desktop. This ssh-tunneling is required to be fine tune to make it

light weight. We can enable as well as disable ssh-tunneling using ltsp configuration file (shown

in Appendix).

In LAN scenario, user gets the same experience as working on local desktop. User can access

local USB devices (e.g. USB flash drive, printer, etc.) and also get Audio playing on remote

desktop. But when users access desktops from outside LAN, they must have PCs with minimum

required configuration to run local OS and web browser. The following section describes the

procedure and technical stuff to access desktop using Internet, i.e. WAN.

6.2 Desktop Access Over Internet (WAN)

Figure6.3explores the part of DeskVirt architecture which is involved in desktop over WAN

scenario. To access desktop over Internet, user needs web browser and other required plug-ins.The web application, developed in PHP, is used to create new desktop and control the re-

mote virtual desktop. This web application runs on central management server. It uses MySql

database system to store and manage the users information and their desktops. When user

logs in to his/her account, it will show already created desktops, if any available. To access

desktop, user first needs to start the desktop. Once desktop has started, the web application

shows view link to show and interact with the remote desktop.

In this project, TightVNC is used to access the remote desktop. There are many other

options available for remote desktop like RealVNC, NX VNC, RedHat SPICE protocol, etc.Most of the VNC versions are insecure over Internet. RedHat SPICE protocol is the best

option to get remote desktop over Internet but it does not have any solution for web browser. To

18


28/50

Figure 6.3: Deskvirt Components Involved To Access Desktop In WAN Scenario

access remote desktop using RedHat SPICE protocol, user has to install client side applications

on his/her PC. To avoid this dependency, VNC is used for remote desktop. TightVNC is

available in Java Applet form. This Java Applet is kept on central management server. When

user clicks on view link, the web browser will load the Java Applet program from central

management server. The web browser runs on client machine, i.e. users PC, must have

installed the Java Plug-in required to load Java Applet. The Java Applet first connects to

central management server. The central management server uses port forwarding to tunnel

VNC traffic to corresponding VAPM server where users desktop is running. User cannot get

audio support and local device support in VNC. The one of the future works is to provide these

supports and also provide sufficient network security to prevent possible cyber attacks.

Figure6.4shows the messages exchange between users workstation and DeskVirt components

when user accesses the remote desktop over Internet using DeskVirt. The detail description of

the above time line Figure is given below.

1. When user opens DeskVirt web application on web browser, it first asks for users cre-

dentials to get in to his/her portal.

2. On successful log in, the web application displays the already created desktops on web

page. For each desktop, there is a start link beside the desktop name.

3. To access desktop, user first needs to start desktop by clicking on the start link.

4. The central management server selects the VAPM server and sends request to start users

virtual desktop.

19


29/50

Figure 6.4: Message Passing Diagram In WAN Scenario

5. VAPM server starts the virtual desktop. After successful start up of the virtual desktop,

VAPM server sends acknowledgement to central management server.

6. To access remote desktop, VNC is being used in this project. VNC server software runs

on VAPM server. But VAPM server is located in internal private network. Thus, it is not

accessible over Internet. To avoid this problem, the central management server forwards

the VNC traffic for started desktop to appropriate VAPM server using port forwarding.

7. Central management server sends acknowledgement to the web application using AJAX

(Asynchronous JavaScript and XML). The web application displays view link for started

desktop as soon as it gets the acknowledgement from central management server.

8. When user clicks on the view link, the web application will load the VNC client Javaapplet from central management server.

9. Once Java applet loads fully, the Java web browser plug-in on the users workstation

executes the applet using JVM (Java Virtual Machine). The applet first asks for password.

This password is the same one which is used by the user during log in to DeskVirt web

application. After successful user authentication, user can view and control the remote

virtual desktop.

The simple deployment of DeskVirt and the results of the experiments performed on DeskVirt

to evaluate it are discussed in next Chapter.

20


30/50

Chapter 7

Deployment And Experiments

Figure-7.1 shows the simple architecture of the DeskVirt which we have deployed. We have

used old configuration PCs(with and without hard-disk) instead of the actual thin clients. In

this deployment, management server runs DHCP server, NFS server, Proxy Server and PHP

web application.

Figure 7.1: Experimental Set-Up

The hardware configuration of management server and VAPM are given in the Appendix.

Installation procedures of every software are given in Appendix.

There are many metrics to measure the performance of the virtual desktop, like disk through-put, CPU utilization, memory utilization, transaction rate (number of users), responsiveness

and start-up time, etc. From users point-of-view, start-up time and responsiveness of the

21


31/50

desktop are important and significant metrics. Start-up time is the amount of time that the

DeskVirt takes between powering on of workstation and the user is getting desktop log in screen.

Responsiveness is the amount of time a virtual desktop takes to return a response to a user

request such as a mouse click or a keyboard key press. As shown in Figure-6.2, the start-up

time can be divided into following time periods.

Thin client starts up time: It is the time from power on of the thin client to the

display of a login screen of DeskVirt. This includes the time that thin client takes to

send DHCP query and gets the DHCP response from the management server, the Linux

kernel download time and the time that downloaded kernel takes to initialize the local

hardware of the thin client.

User-to-VM mapping time: It is the period between the time that user logged in to

the DeskVirt console and users remote virtual desktop, i.e. VM, starts fully. The VM

startup time is the main element of this time period.

LTSP startup time: It is the amount of time that LTSP client software takes to

mount the required file system from VM to thin client and the time it takes to create

new user session. When users remote desktop starts, the kernel, which is running on thin

client, mounts the file system from the VM which includes LTSP client software. Once

file system mounted successfully, the kernel runs LDM (LTSP Display Manager) which

shows the log in screen of the remote desktop to the user.

Besides the start up time, the responsiveness is the another important metric which can be

used to measure the performance of the DeskVirt. It is very tough to measure the exactresponse time which includes the time that user sends request (e.g. mouse click), the request

gets executed on remote desktop, the users workstation gets the response and it then renders

on its screen. The main time period that merely affects the response time is the execution time

of the request. The rest of the time periods are dependent on the network link capacity and

users workstation capacity. The following sections show the results of the experiments that we

have done for start-up time and responsiveness.

7.1 Experiment 1: Start Up Time of DeskVirt In LANScenario

The aim of this experiment is to measure the DeskVirt start up time in LAN scenario. The

start up time of the DeskVirt is compared with the start up time of standalone desktop, i.e.

the OS runs on local traditional PC. The DeskVirt start up time is divided in to three time

periods as shown in Figure-6.2. This experiment was done on the topology shown in Figure-7.1.

The thin client start up time is dependent on the capacity of Ethernet Card and the capacity

of the network link. When thin client gets the address of TFTP server, it will download the

stripped down version of Linux kernel and the initial file system (is the compressed image filecalled as initrd) which are required to kernel to initialize the local hardware. The size of Linux

kernel is around 3.6 MB and the size of initrd file is around 9 MB. We have measured from

22


32/50

the experiments that the workstation with 100 Mbps Ethernet card, connected with 10 Mbps

network, will take less than 2 seconds to download the kernel and initrd file.

The User-to-VM mapping time is dependent on the virtual desktop, i.e. VM, boot up time.

The boot up time of the operating system on VM is generally faster than the boot up time on

standalone PC because the VM does not need to initialize the actual physical hardware. The

hardware of the PM has already been initialized by the host operation system in the virtualized

environment. This reduces a lot of time in the boot up process of the guest operating system,

i.e. VM. In this experiment, we have measured the boot up time of the Ubuntu 10.04 desktop

operating system on the regular desktop machine with core-2-duo Intel processor and 1 GB

memory. We have also measured the boot up time of the virtual desktop in the following

situations.

Case-I: Only one virtual desktop is starting up.

Case-II: Two virtual desktops are starting up at the same time.

Case-III: Three virtual desktops are starting up at the same time.

Case-IV: Four virtual desktops are starting up at the same time.

Figure 7.2: Virtual Desktop Start Up Time Results

The Figure7.2shows the experiment results. In these experiments, we have assumed that

the PM is up. Thus, PM start up time is ignored for this experiment. During the experiment,

the PM has already ported with two virtual desktops and both were running Linux kernel

compilation process. Each virtual desktop is provided with 2 VCPU and 1GB memory. The

23


33/50

size of the virtual desktop disk image is 8 GB.

Once VM has started up, the kernel running on workstation mounts the required file system

from the VM. The kernel then starts LTSP client side scripts to establish session. The LTSP

start up time is highly dependent on how many network devices (switches or hubs) are placed

between the workstation and VAPM server ( where VM is running). From the experiments, we

have measured that it takes 20 to 40 seconds dependent on the number of switches in between.

In this experiment, we have considered the extreme case where the users workstation and the

VAPM server are placed in different network, i.e LAN.

From the above experiments, we have concluded that the total start up time of the DeskVirt

remains within 60 seconds which is comparable with the start up time of the operating system

boots on regular PC. Moreover, the number of VMs starting at the same time does not affect

the performance significantly.

7.2 Experiment 2: Applications Performance Running

On DeskVirt

As we have seen, user experience can be measured using responsiveness metric. Responsiveness

of the DeskVirt merely depends on the execution time of applications. The target audience

of the DeskVirt could be students of institution and employees of small enterprises. Most of

the time, they work on applications like web browser, program compilation or execution, etc.

Thus, in this experiment, the performance of the web browser on virtual desktop was measured

and compared with the same when it runs on standalone PC. We have used Mozilla Firefox

web browser. To measure the performance of the web browser, we measured the execution time

of various javascripts because it runs on client side, i.e. on remote virtual desktop. We have

also measured the compilation time of Linux kernel. The compilation of Linux kernel is CPU

as well as IO intensive process. We ran the kernel compilation on virtual desktop as well as

standalone PC.

For this experiment, SunSpider javascript benchmark [14] is used. SunSpider benchmark

conducts JavaScript tests, like generation of a tagcloud from JSON input, a 3D raytracer,

cryptography tests, code decompression, etc. The first experiment is intended to compare the

execution time of this benchmark running on virtual desktop with the same running on tradi-

tional standalone desktop machine. Table-7.1shows the configuration of the virtual desktops

and the benchmark execution time on them. The last column shows the configuration of the

standalone PC and the benchmark execution time on it. In this experiment, we ran this bench-

mark at the same time on all virtual desktops. From these results, we can see that though the

resource configuration of virtual desktops are lesser than the standalone PC, the difference in

the benchmark execution time is lesser than 100 milli seconds. Most of the desktop applications

are not hard deadline. Thus, with this difference of hundreds of milli seconds, users dont get

bad experience with respect to the standalone PC. To reduce the cost, the administrator wants

to squeeze as many virtual desktop as possible on the same physical machine (PM). In this

24


34/50

Table 7.1: Configuration of Virtual Desktop (VD) And Results of SunSpider Benchmark

VD1 VD2 VD3 VD4 VD5 VD6 VD7 VD8 Stand Alone

PC

CPU 1 1 1 1 1 1 1 1 Core2Duo

Memory (MB) 1024 1024 1024 1024 1024 1024 1024 1024 3072

Execution

Time (msec)

384.2 373.8 381.6 380.4 396.4 380 368.2 370 286.1

type of situations, the performance of the applications running on the remote virtual desktop

should be acceptable. To ensure this, we did experiment with the virtual desktops with con-

figurations shown in table-7.2and table-7.3. In this experiment, we have hosted eleven virtual

desktops on the same VAPM server. On four virtual desktops, we ran Linux kernel compilation.During kernel compilation process on these four virtual desktops, we ran SunSpider JavaScript

benchmarks on rest of the seven virtual desktops. The number of virtual CPUs was assigned

to virtual desktop such that each virtual desktop only gets fraction of the physical CPU core.

In this scenario, we got acceptable results for SunSpider benchmark even though each virtual

desktop got only fraction of physical CPU core.

Table 7.2: Configuration of Virtual Desktop (VD) And Results of SunSpider Benchmark

VD1 VD2 VD3 VD4 VD5 VD6 VD7

CPU 1 1 1 1 1 1 1

Memory (MB) 512 512 512 512 512 512 512

Execution Time

(msec)

388.2 384.7 352.3 413.3 375.3 447.4 350.1

Table 7.3: Configuration of Virtual Desktop (VD) And Results of Linux Kernel Compilation

VD8 VD9 VD10 VD11

CPU 2 2 1 1

Memory (MB) 1024 1024 512 512

Execution Time (min-

utes)

146.08 143.27 149.72 152.65

In last experiment, we ran the compilation of the Linux kernel on all the virtual desktop at

a time. This experiment is intended to ensure that the performance of the highly CPU and IO

intensive applications/processes running on virtual desktop remain approximately same as thoserunning on standalone PC. The number of virtual desktops and their resource configurations

are given in table-7.4. The last column shows the kernel compilation time on standalone PC.

25


35/50

Linux kernel compilation process is very long running process because the size of the Linux

kernel is approximately 15 million lines of code. Normally, students and employees compile

programs which are range within thousands lines of code. There would be minor difference in

normal program compilation time running on virtual desktop compare to running on standalone

PC. Thus, the user gets the approximately same experience on virtual desktop as he/she works

on standalone PC.

Table 7.4: Configuration of Virtual Desktop (VD) And Results of Linux Kernel Compilation

# Virtual Desktops 2 3 4 5 Stand Alone PC

CPU 2 2 2 2 Core2Duo

Memory (MB) 1024 1024 1024 1024 3072

Execution Time (min-

utes)

122.62 130.13 137.8 146.37 124.37

26


36/50

Chapter 8

Conclusions And Future Work

DeskVirt significantly reduces hardware maintenance cost and the time of hardware upgrada-

tion and maintenance for small enterprises and educational institutes. It provides flexibility in

provisioning of resources to users desktop dynamically. There are some proprietary products

exist, but they are costly to deploy for small-scale business or educational institutes. The aim

of this project is to provide open source solution for remote desktop virtualization with dy-

namic resource provisioning facility. Since the solution is based on open source, it is possible

for us to implement different VM migration and PM consolidation algorithms to improve the

performance of the system.

User can access desktop using Internet. Internet is the public network and also insecure.

In this project, tightVNC (a modified version of VNC) is used to access the remote desktop

over Internet. VNC does not provide any network security. Moreover, tightVNC also does not

provide audio support, thus use cannot get audio from the remote desktop over Internet. This

project will be extended with following functionalities and optimizations

Audio and Local Device Support In Desktop Access Over Internet Scenerio:

In this project, tightVNC is used to access and control remote desktop over Internet.

tightVNC does not provide support for remote audio as well as local device redirection.

Thus, When users access their desktops over Internet, they will not get audio playing

on remote virtual desktop. Moreover, users cannot connect local devices, like USB flash

drive, local printer, etc, to remote virtual desktop. We can extend this project by addingthese two features.

Add Network Security In Web Application:

Internet is the public network. The data transfer over Internet are accessible to every one

who is connected to Internet. Thus malicious user connected to Internet can exploit this

weakness of the Internet to do cyber attacks, like data sniffing, data modification, session

hijacking, etc. To avoid cyber attacks, data should be encrypted before they sent out on

the public Internet. DeskVirt web application is not secured over Internet. The addition

of network security in DeskVirt web application is an extension of this project.

Automatic Dynamic Resource Provisioning

In current state of DeskVirt, VM placement is static. To exploit the features of virtualiza-

27


37/50

tion, like VM consolidation and live migration, dynamic resource provisioning algorithm

needs to include in this project. This algorithm moniters the resources utilization of each

running desktop and provision resources dynamically to desktops as per their require-

ments.

28


38/50

Bibliography

[1] Citrix XenDesktop. http://www.citrix.com/English/ps2/products/feature.asp?

contentID=2300341,2012.

[2] Content of initrd.img File. http://www.ibm.com/developerworks/linux/library/

l-initrd/index.html,2012.

[3] DHCP Dynamic Host Configuration Protocol. http://en.wikipedia.org/wiki/

Dynamic_Host_Configuration_Protocol,2012.

[4] DHCP Server Installation in Ubuntu. https://help.ubuntu.com/10.04/serverguide/

C/dhcp.html, 2012.

[5] LTSP. http://www.ltsp.org/, 2012.

[6] LTSP Configuration File. http://manpages.ubuntu.com/manpages/lucid/man5/lts.

conf.5.html, 2012.

[7] LTSP Document. http://sourceforge.net/apps/mediawiki/ltsp/index.php?title=

Ltsp_LtspDocumentationUpstream,2012.

[8] LTSP Installation on Ubuntu.https://help.ubuntu.com/community/ThinClientHowto,

2012.

[9] NFS Network File System. http://en.wikipedia.org/wiki/Network_File_System_

(protocol), 2012.

[10] Openthinclient. http://openthinclient.org/home, 2012.

[11] PXE. http://en.wikipedia.org/wiki/Preboot_Execution_Environment, 2012.

[12] RedHat SPICE Protocol For Remote Desktop. http://www.spicespace.org/, 2012.

[13] Ssh-Tunneling. http://en.wikipedia.org/wiki/Tunneling_protocol, 2012.

[14] SunSpider JavaScript Benchmark. http://www.webkit.org/perf/sunspider/

sunspider.html, 2012.

[15] TFTP Trivial File Transfer Protocol. http://en.wikipedia.org/wiki/Trivial_File_

Transfer_Protocol,2012.

[16] Thin Client. http://en.wikipedia.org/wiki/Thin_client, 2012.

29
http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300341http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300341http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300341http://www.ibm.com/developerworks/linux/library/l-initrd/index.htmlhttp://www.ibm.com/developerworks/linux/library/l-initrd/index.htmlhttp://www.ibm.com/developerworks/linux/library/l-initrd/index.htmlhttp://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocolhttp://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocolhttp://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocolhttps://help.ubuntu.com/10.04/serverguide/C/dhcp.htmlhttps://help.ubuntu.com/10.04/serverguide/C/dhcp.htmlhttp://www.ltsp.org/http://manpages.ubuntu.com/manpages/lucid/man5/lts.conf.5.htmlhttp://manpages.ubuntu.com/manpages/lucid/man5/lts.conf.5.htmlhttp://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstreamhttp://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstreamhttp://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstreamhttps://help.ubuntu.com/community/ThinClientHowtohttps://help.ubuntu.com/community/ThinClientHowtohttp://en.wikipedia.org/wiki/Network_File_System_(protocol)http://en.wikipedia.org/wiki/Network_File_System_(protocol)http://en.wikipedia.org/wiki/Network_File_System_(protocol)http://openthinclient.org/homehttp://en.wikipedia.org/wiki/Preboot_Execution_Environmenthttp://www.spicespace.org/http://en.wikipedia.org/wiki/Tunneling_protocolhttp://www.webkit.org/perf/sunspider/sunspider.htmlhttp://www.webkit.org/perf/sunspider/sunspider.htmlhttp://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocolhttp://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocolhttp://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocolhttp://en.wikipedia.org/wiki/Thin_clienthttp://en.wikipedia.org/wiki/Thin_clienthttp://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocolhttp://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocolhttp://www.webkit.org/perf/sunspider/sunspider.htmlhttp://www.webkit.org/perf/sunspider/sunspider.htmlhttp://en.wikipedia.org/wiki/Tunneling_protocolhttp://www.spicespace.org/http://en.wikipedia.org/wiki/Preboot_Execution_Environmenthttp://openthinclient.org/homehttp://en.wikipedia.org/wiki/Network_File_System_(protocol)http://en.wikipedia.org/wiki/Network_File_System_(protocol)https://help.ubuntu.com/community/ThinClientHowtohttp://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstreamhttp://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstreamhttp://manpages.ubuntu.com/manpages/lucid/man5/lts.conf.5.htmlhttp://manpages.ubuntu.com/manpages/lucid/man5/lts.conf.5.htmlhttp://www.ltsp.org/https://help.ubuntu.com/10.04/serverguide/C/dhcp.htmlhttps://help.ubuntu.com/10.04/serverguide/C/dhcp.htmlhttp://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocolhttp://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocolhttp://www.ibm.com/developerworks/linux/library/l-initrd/index.htmlhttp://www.ibm.com/developerworks/linux/library/l-initrd/index.htmlhttp://www.citrix.com/English/ps2/products/feature.asp?contentID=2300341http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300341


39/50

[17] tightVNC, a modified version of VNC. http://www.tightvnc.com/,2012.

[18] Virtual Network Computing (VNC). http://en.wikipedia.org/wiki/Virtual_

Network_Computing,2012.

[19] VMWare ESX. http://en.wikipedia.org/wiki/VMware_ESX, 2012.

[20] VMWare View. http://www.vmware.com/products/view/overview.html, 2012.

[21] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt,

and A. Warfield. Xen and the art of virtualization. In Proceedings of the nineteenth ACM

symposium on Operating systems principles, pages 164177. ACM, 2003.

[22] C. Clark, K. Fraser, S. Hand, J.G. Hansen, E. Jul, C. Limpach, I. Pratt, and A. Warfield.

Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium

on Networked Systems Design & Implementation-Volume 2, pages 273286. USENIX As-

sociation, 2005.

[23] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori. kvm: the linux virtual machine

monitor. In Proceedings of the Linux Symposium, volume 1, pages 225230, 2007.

[24] T. Wood, P. Shenoy, A. Venkataramani, and M. Yousif. Black-box and gray-box strategies

for virtual machine migration. In Proc. NSDI, 2007.

30
http://www.tightvnc.com/http://www.tightvnc.com/http://en.wikipedia.org/wiki/Virtual_Network_Computinghttp://en.wikipedia.org/wiki/Virtual_Network_Computinghttp://en.wikipedia.org/wiki/Virtual_Network_Computinghttp://en.wikipedia.org/wiki/VMware_ESXhttp://www.vmware.com/products/view/overview.htmlhttp://www.vmware.com/products/view/overview.htmlhttp://en.wikipedia.org/wiki/VMware_ESXhttp://en.wikipedia.org/wiki/Virtual_Network_Computinghttp://en.wikipedia.org/wiki/Virtual_Network_Computinghttp://www.tightvnc.com/


40/50

Appendices

31


41/50

Appendix A

Hardware Configuration of Servers

Used For DeskVirt Deployment

The hardware configurations of the machines which were used in deployment of DeskVirt (shown

in Figure-7.1) are given below. In this deployment of DeskVirt, there was only one management

server which worked as central, local management server and NFS server.

1. Management Server

CPU : Intel 2.68 GHz Quard Core Processor

Memory : 2 GB RAM

Network Card : 100 Mbps Ethernet Card

2. VAPM

CPU : 2.27GHz 8 Core Intel Xeon CPU

Memory : 8 GB RAM

Network Card : 1 Gbps Ethernet Card

The management server, VAPM and workstations were connected with the 100 Mbps net-

work switch. KVM hypervisor and LTSP version-5 were used in this deployment of DeskVirt.

Ubuntu(Linux) 10.04 operating system was used for remote virtual desktop operating system.

32


42/50

Appendix B

Central Management Server Software

Installation

Central management server runs PHP web application and MySQL database system. To run

PHP web application, apache web server is required. The installation procedures for these

software on Ubuntu 10.04 server are given below.

Installation of MySql:

# apt-get install mysql-server mysql-client

Installation of Apache2:

# apt-get install apache2

Installation of PHP5:

# apt-get install php5 libapache2-mod-php5

After installation of PHP5, restart the apache web server by using

following command

# /etc/init.d/apache2 restart

33


43/50

Appendix C

Sofware Installation On NFS Server

NFS server stores the disk image file of the user desktop (i.e. VM). The VAPM (Virtualization

Aware Physical Machine) mounts disk image file of the VM from the NFS server. NFS is the

client-server protocol. In our case, the VAPM server is the client machine and NFS server is the

server machine for NFS protocol. The procedure to install and configure NFS server software

on Ubuntu 10.04 OS is given below.

# apt-get install nfs-kernel-server

The above command installs required packages for NFS server software. Once the software

has installed, we have to specify the path of the file system we want to export. We also have

to specify the IP address of the liable machine to import the file system. To do these, we need

to configure the export configuration file available at

/etc/exports

in Ubuntu 10.04. For instance, the home directory is required to export to other machine whose

IP address is 192.168.1.10. The following line we have to add in

/etc/exports

file at NFS server.

/home 192.168.1.10(rw,fsid=0,insecure,no_subtree_check,async)

NFS client side software can be installed using following command.

# apt-get install nfs-common

After the installation, we have to inform the NFS server IP address to the NFS client

software to mount the file system. The following command is used to do the same.

# mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/ /mnt

For instance, the IP address of the NFS server is 192.168.1.2. To mount the home directoryof the NFS server at client machine (which is exported by NFS server in above example), we

have to run following command.

34


44/50

# mount -t nfs4 -o proto=tcp,port=2049 192.168.1.2:/ /mnt

The above command mount the home directory of the NFS server in to the mnt directory of

the client machine.

35


45/50

Appendix D

Software Installation On VAPM Server

VAPM server runs the users virtual desktop (i.e. Virtual Machine). To run VM, hyper visor

(like Xen and KVM) have installed on the server. This server also mounts the disk image of the

users desktop from the NFS server. Thus, the NFS client side software should be installed on

VAPM server. The NFS client side software installation procedure is given in previous chapter.

The following commands are used to install KVM hyper visor on Ubuntu 10.04 OS.

# apt-get install qemu-kvm ubuntu-vm-builder bridge-utils

To install Xen hyper visor, we have to compile Xen source till Ubuntu 10.04 OS. But from

Ubuntu 11.10 release, we can directly install Xen hyper visor using aptget command. The

following commands are used to install the latest available Xen version on Ubuntu 11.10 OS.

# apt-get install xen-hypervisor-4.1-amd64 xen-utils-4.1 xenwatch \

xen-tools xen-utils-common xenstore-utils

The above command install xen 4.1 hyper visor on Ubuntu 11.10 OS. After installation,

restart the server. Now onward, the server shows an entry in Grub menu to boot up kernel with

Xen hyper visor. Choose the Xen entry from grub menu. Once the OS boots up successfully,

run the follwoing command to check whether Xen is running.

# xm info

The above command shows the information about the server resources, the Xen version, etc.

36


46/50

Appendix E

Software Installation On Local

Management Server

Install DHCP Server Software[4]

# apt-get install dhcp3-server

Configure DHCP ServerThe above command install DHCP server and generate sam-

ple configuration file at /etc/dhcp3/dhcpd.conf. The sample configuration file, when one

thin client is running, would be look like as below.

subnet 192.168.1.0 netmask 255.255.255.0 {

# IP address range for thin clients exists in subnet

range 192.168.1.11 192.168.1.20;

option domain-name-servers 192.168.1.2;

option broadcast-address 192.168.1.255;

option routers 192.168.1.2;

option subnet-mask 255.255.255.0;

option root-path "/opt/ltsp/amd64";

# LTSP file system path located at VM

filename "ltsp/amd64/pxelinux.0";

# pxelinux.0 is a program which is used# for booting linux kernel over network

next-server 192.168.1.2;

# This is the IP address of local management

# server. This address is sent to the thin client

# in DHCP response. This IP address is used by thic

# client to download the kernel and initrd file.

}

The above configuration file can be changed as per subnet IP address scheme of a pertic-

ular network.

37


47/50

Appendix F

Software Installation On Virtual

Machine

This chapter describes, how to install and configure LTSP server and client environment. All

commands will run on virtual machine (i.e. virtual desktop).

LTSP Server And Client[8] The following command install LTSP server software.

# apt-get install ltsp-server

The above command installs other necessary software for LTSP, For example, NFS, TFTP

etc. On server machine, We have to open port 69 for TFTP daemon, if firewall runs.

After LTSP server software installation, client runtime environment can be built by follow-

ing command. This command creates filesystem for thin client. It takes several minutes

to install.

# ltsp-build-client

As LTSP uses SSH tunneling to establish connection between client and server, we have

to install Open-shh-server on server machine.

# sudo apt-get install openssh-server

The following command generates ssh-key, which will be used by client to connect with

server.

# ltsp-update-sshkeys

On any changes in client configuration(lts.conf) file or VM IP address, following com-

mands have to run on VM.

# ltsp-update-sshkeys# ltsp-update-image

38


48/50

LTSP Configuration File (lts.conf)[6]: lts.conf is the main configuration file for

LTSP. This file gets parsed when LTSP client starts up. The configuration settings in

this file are divided in to sections. The section defined by [default] gets applied to all

clients. This file is located at

/var/lib/tftpboot/ltsp/i368/lts.conf

or

/var/lib/tftpboot/ltsp/amd64/lts.conf

based on the ltsp client installation. Simple example of configuration file is given below.

[default]

# SOUND=True adds audio support at client side.

SOUND=True

# LDM_DIRECTX=True allows greater scalability and performance.

# Turn this off if you want greater security instead.

LDM_DIRECTX=True

# LDM_SYSLOG=True writes to servers syslog

LDM_SYSLOG=True

39


49/50

Appendix G

Modification In initrd File System

(initrd.img)

Thin client downloads kernel and initrd file system from the management server on starts up.

To map users thin client to appropriate virtual desktop, we have modified initrd file system.

Using following procedure, we can modify initrd file system.

initrd.img is in gzip format. So move initrd.img to initrd.gz as shown below.

# mv initrd.img initrd.gz

Unzip the initrd.gz file as shown below.

# gunzip initrd.gz

After unziping the initrd.gz file, the initrd is further in cpio newc format. So extract the files

from initrd using cpio newc format as shown below.

# mkdir temp

# cd temp

# cpio -id $ ../initrd

Gzip the archive file.

# gzip initrd

40


50/50

Move file as an image file. You can use the newinitrd.img as your new boot image.

# mv initrd.gz initrd.img

We have added DeskVirtd daemon. This daemon is used in thin client to users desktop

mapping. It communicates with the management server. It needs thin client IP address andmanagement server IP address. To supply these parameters, we have modified udhcp script

located at

/scripts/init-premount/udhcp.

The following shell script code has been added in this file to execute DeskVirtd daemon.

MAC_ADDR=ifconfig $interface | grep HWaddr | sed "s/ */\ /g" | cut -d" " -f6

Management_Server_ADDR=echo $tftp

/DeskVirtd $Management_Server_ADDR $iptftp=cat /tmp/tftpserver

When DeskVirtd gets virtual desktop IP address, it will keep in

/tmp/tftpserver/

folder. The LTSP client software usestftpvariable to get the IP address of the remote desktop.

Thus, the virtual desktop IP address is assigned to tftpvariable.

Documents

Dhaval Mtmuito Report