DeskVirt : Low Cost Computing Using Virtualization For Remote Desktop

Transcription

1 DeskVirt : Low Cost Computing Using Virtualization For Remote Desktop Submitted in partial fulfillment of the requirements for the degree of Master of Technology by Manvar Dhaval R. Roll No: under the guidance of Prof. Anirudha Sahoo Department of Computer Science and Engineering Indian Institute of Technology, Bombay 2012

2 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: ) is approved for the degree of Master of Technology in Computer Science and Engineering from Indian Institute of Technology, Bombay. Prof. Anirudha Sahoo CSE Dept., IIT Bombay Supervisor Prof. Varsha Apte CSE Dept., IIT Bombay Internal Examiner Prof. P. Kulkarni CSE Dept., IIT Bombay Aditional Internal Examiner Prof. Tom Mathews Civil Dept., IIT Bombay Chairperson Place: IIT Bombay, Mumbai Date: 2012 i

3 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 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 have developed 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 this thesis.

5 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 computation happens 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 virtualization technology 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 possible for us to implement different VM migration and PM consolidation algorithms to improve the performance of the system.

6 Contents 1 Introduction 1 2 Related Technologies 5 3 Problem Formulation 7 4 Contributions In Development Of DeskVirt 8 5 DeskVirt Architecture Central Management Server Local Management Server Virtualization Aware Physical Machine (VAPM) NFS (Network File System) Server [9] User s Workstation DeskVirt Access Scenarios Desktop Access Within LAN Desktop Access Over Internet (WAN) Deployment And Experiments Experiment 1: Start Up Time of DeskVirt In LAN Scenario Experiment 2: Applications Performance Running On DeskVirt 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 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 List of Figures 5.1 DeskVirt Architecture Functional Diagram (DeskVirt Core Components And Required software On Them) Deskvirt Components Involved To Access Desktop In LAN Scenario Message Passing In LAN Scenario Deskvirt Components Involved To Access Desktop In WAN Scenario Message Passing Diagram In WAN Scenario Experimental Set-Up Virtual Desktop Start Up Time Results iii

9 List of Tables 1.1 Comparison of Remote Desktop Software Configuration of Virtual Desktop (VD) And Results of SunSpider Benchmark Configuration of Virtual Desktop (VD) And Results of SunSpider Benchmark Configuration of Virtual Desktop (VD) And Results of Linux Kernel Compilation Configuration of Virtual Desktop (VD) And Results of Linux Kernel Compilation 26 iv

10 Chapter 1 Introduction The complexity of software and their demand of computing power is an ever increasing phenomenon. 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 required 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 users logged in. solutions. There are no load balancing/consolidation schemes available in such Capability of live migration[22] available with virtual machines using virtualization technologies (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 an efficient 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 and standalone, available for remote desktop over Internet, e.g. VNC[18] (Virtual Network Computing), 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 security purpose) to use over Internet. Table 1.1 shows 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 used by small enterprises and educational institutes. Easy to deploy and low level administrator maintenance. 2

12 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.) Developed In (Software developed in Java is heavy to execute than pure Shell Script or C language) USB Support At Client (User can use USB attached device from client side.) Audio Support At Client (User can get Audio from server.) Allows Local execution of Application (User can execute specific applications on thin client locally.) Yes Yes Yes Yes Java Shell Script C++/Java C/C++ Yes Yes No Yes Yes Yes No Yes Yes Yes No Yes GUI Export (How does server export desktop s display to client?) SSH -X XDMCP (X Display Manager Control Protocol) or SSH -X RFB (Remote Frame- Buffer) SPICE Protocol Client side software Not Required Not Required Required (VNC client) Required (SPICE client) Does web browser based solution available? Thin client based solution? No No Yes No 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 doesn t solve the security issues which basically exist 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 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 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 desktop 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 virtualization product offered by VMWare. It runs on host Operating System as a software. 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 user s PC or thin client. It is used to access user s 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 configure 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 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 Windows 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 machines 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 user s virtual desktop environments and establishes 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 virtual desktop and user s endpoint devices. Desktop Receiver: It is installed on user s 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, deployment of XenDesktop is not affordable by small enterprises. It only supports Windows OSes as Desktop. End user s device is required to have capability of running Desktop Receiver software. Moreover, it cannot be used on thin clients without local disk. 6

16 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. User s 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 desktop. By leveraging the facilities provided by virtualization like dynamic resources provisioning and live migration, server s resources can be utilized efficiently. There are some proprietary products already available in the market, e.g. VMware View, Citrix XenDesktop, etc, as discussed 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 user s 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 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 machines, 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, user s workstation was downloading kernel twice for user s 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. user s workstation downloading Linux kernel twice, single operating system per user, etc. 8

18 Modified existing architecture to include web based solution and made it more robust. Developed web application for remote desktop over Internet. For web application, PHP server side scripting language has been used. To store user s desktop s information, 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 Chapter 5 DeskVirt Architecture Figure-5.1 shows the high level architecture and various components involved in DeskVirt. Internet NFS Server Central Management Server Desktop Over Internet Switch... Local Management Server and Virtualization Aware Physical Machines (VAPM) Thin Clients or Old PCs... Local Management Server and Virtualization Aware Physical Machines (VAPM) Thin Clients or Old PCs Figure 5.1: DeskVirt Architecture This architecture is neither fully centralized nor fully distributed. The most of the information required to access user s 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.2 depicts the functional diagram of the DeskVirt system. DeskVirt s 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 programs for DeskVirt and the daemons shown in the pink circles are off-the-self open source software. 10

20 Apache Web Server MySql DBMS Central Management Server PHP Web App. RPD Local Management Server DMD NFS Server Daemon Linux Kernel LTSP Client Workstation DeskVirtd NFS Server VMGen Desktop Gen Hyper visor DVD Virtualization Aware Physical Machine (VAPM Server) Developed Sofrware Off-the-shelf Software LTSP Server Virtual Desktop User Session Status Server or Workstation Control/Data Flow 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. User s Workstation 5.1 Central Management Server The central management server is a multi-purpose server in this architecture. The central management 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 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 user s 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 user s workstation. It also gives the IP address of the system from where the user s diskless workstation can get the required Linux kernel which is used to boots it up. 2. TFTP (Trivial File Transfer Protocol) server [15]: User s 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 map users to their appropriate desktops. When user starts workstation, it first asks for user s credential, i.e. use name and password. Once DMD has identified the user, it then maps user s 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 user s 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 user s desktop runs on this PM. This PM mounts user s desktop disk image from NFS server. The following daemons run on every VAPM to automatically manage user s 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 virtualization environment. It runs on bare hardware in the highest privileged level. Multiple 12

22 virtual machines(domains) can run on Xen. Xen provides isolation among running domains 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 requests from DMD. The main task of this daemon is to start user s 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 (User s Desktop) : User s 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 user s session. The functionality and requirement of this 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 user s 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 client s 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 user s 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 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 user s 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 User s 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 dumb terminal 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, user s workstation needs different types of software. 1. Desktop Over LAN : User can access desktop using diskless thin client or old configuration PCs with local disk. User s workstation runs very stripped down version of the Linux kernel. To map user s workstation to appropriate user s remote desktop, the daemon running on management server needs user s information, i.e. user name and password. To get these information, when Linux kernel loads on user s workstation, it first loads a program (named as DeskVirtd) which asks for user s credential. This program sends user s 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 desktop over 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 user s workstation to remote virtual desktop. 14

24 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 boot up and initialize the local hardware. The workstation with local disk do not need to download this Linux kernel as we can store it locally. Figure 6.1 depicts the enlarged view of LAN part shown in figure 5.1. The architecture shown in Figure 6.1 is required to reduce the load on the central management 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 user s workstation, there are many message exchanges among different servers and user s workstation. Figure 6.2 shows these messages and their relative timing with respective to the start up of workstation. Two different colors in Figure 6.2 shows 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 Figure 6.2 are listed below in detail. 1. When user starts workstation, it first sends request to DHCP server using PXE enabled Ethernet card. As per the architecture, DHCP server is running on the local management server, thus it gets DHCP request. 15

25 DHCP Server Management Scripts Resource Provisioning Scripts To Central Management Server Guest Domains (Virtual Machines) Dom0 or Host OS Xen Hyper-Visor Local Management Server Physical Hardware Virtualization Aware Physical Machine... Diskless Thin Client or Old PCs With Local Disk 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 contains 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 doesn t 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, Operating System, etc.) to workstation. 6. DeskVirtd daemon, running on user s 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 user s desktop to one of the running VAPM server or starts new VAPM server based on the load on running servers. The DVD daemon, running on VAPM server s host operating system (e.g. Domain-0 in Xen), gets the 16

26 TC startup time User-to-VM mapping time *Thin Client (TC) Management Server Host OS or Domain DHCP Req. TC IP + TFTP Server IP TC downloads kernel TC IP, uname, passwd user's desktops details Desktop ID VM startup time ACK, VM IP VM ID ACK 8 Start VM Virtual Machine User to VM Mapping Ltsp startup time Mount LTSP Client File System Session Created TC is connecting to user's VM after mapping * Diskless Workstation 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 user s desktop status. It then sends the IP address of the user s virtual desktop, i.e. VM, to workstation. 9. The daemon running on workstation gets the desktop s 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 user s 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 can use local devices like USB flash drive, local printer, etc. User Session Status daemon, which is running on user s virtual desktop, keeps track of the status of user s session, i.e. user is logged 17

27 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 management 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 user s 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 user s workstation and remote desktop. So, if user moves mouse or presses key on keyboard, the client software running on workstation will send these information through ssh tunnel. It needs high computation capacity to encrypt and to decrypt these messages over ssh. Thus, user s 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) Figure 6.3 explores 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 remote virtual desktop. This web application runs on central management server. It uses MySql database system to store and manage the user s 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 Apache Web Server MySql DBMS PHP Web Application Internet User PC With Web Browser Guest Domains (Virtual Machines) Central Management Server Dom0 or Host OS NFS Server Switch Xen Hyper-Visor Physical Hardware Virtualization Aware Physical Machine 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. user s 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 user s 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. Figure 6.4 shows the messages exchange between user s 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 user s credentials 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 user s virtual desktop. 19

29 * User PC Central Management Server 1 Usre Login VAPM User Name, Passwd 3 Display Available Desktop For User Start Desktop 2 4 Send Desktop Information ACK 5 Virtual Machine (Desktop) Start VM 6 Port Forwading 9 ACK Download VNC Client View And Control Desktop Using VNC 7 8 VNC Traffic Forwarded To VAPM * PC with web browser 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 Java applet from central management server. 9. Once Java applet loads fully, the Java web browser plug-in on the user s 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 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. DHCP Server NFS Server Management Scripts PHP Web Application Internet Management Server 100 Mbps Switch Virtualization Aware Physical Machine (KVM Hypervisor) PCs With Local Disk 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 throughput, CPU utilization, memory utilization, transaction rate (number of users), responsiveness and start-up time, etc. From user s point-of-view, start-up time and responsiveness of the 21

31 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 user s 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 user s 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 exact response time which includes the time that user sends request (e.g. mouse click), the request gets executed on remote desktop, the user s 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 user s 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 LAN Scenario 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 file called 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