LiveLab : What are the requirements of a Virtual Laboratory?

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

LiveLab: What are the requirements of a

Virtual Laboratory?

by

Denis Moret

LIU-IDA/LITH-EX-A-08/015-SE

2008-02-21

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

Linköping University

Department of Computer and Information Science

Final Thesis

LiveLab: What are the requirements of a

Virtual Laboratory?

by

Denis Moret

LIU-IDA/LITH-EX-A-08/015-SE

2008-02-21

Supervisor: Anders Larsson

Department of Computer and Information and Science

Examiner: Dr. Erik Berglund

Abstract

This thesis presents the different ways that have been achieved to improve and widen the interaction possibilities between LiveLab users. LiveLab is a vir-tual laboratory used at IDA (Institutionen f¨or datavetenskap / The Department of Computer and Information Sciences) at Link¨opings Universitet. This virtual laboratory is a virtual machine running an Kubuntu Linux1distribution thanks to VMware 2 Player. It was created at the HCS (Human-Centered Systems) division of IDA. Aiming to be used in more and more courses, LiveLab may present a lack of certain functionalities. Thus thesis tries to shows how the development of applications may fulfil this lack.

Keywords: LiveLab, virtual laboratory, Linux, Ubuntu, VMware, virtual-ization, virtual machine

1_{Linux is an operating system based on Unix. It is one of the most prominent examples of}

free software and open source development.

2_{VMware, Inc. is a publicly-listed company, develops proprietary virtualization software}

products for x86-compatible computers, including both commercially-available and freeware versions

Acknowledgements

I would like to thank Anders Larsson and Erik Berglund to have given me the opportunity of doing my thesis at IDA and for the help they provided to guide me through the work until the end.

I would also like to give my greatest thanks to my family who supported me during my time spent in Sweden.

Furthurmore, I would like to thank my girlfriend, Senem, for her love and her support during all my studies.

Finally thanks to all my other friends for the great times we had during this experience abroad.

Contents

1 Introduction 6 1.1 LiveLab . . . 6 1.2 Research question . . . 7 1.3 Scenarios . . . 7 1.3.1 Deployment . . . 7 1.3.2 Environment creation . . . 7 1.3.3 Resources requirement . . . 8 1.3.4 User interactions . . . 8 2 Related work 9 2.1 Virtual Laboratories . . . 9 2.2 Collaboratories . . . 11 2.3 Contribution . . . 12 2.4 Method . . . 12 3 Background 13 3.1 Virtualization . . . 13

3.1.1 Different virtualization techniques: . . . 14

3.1.2 Virtualization examples . . . 17

3.2 Virtual machine . . . 17

3.2.1 System virtual machines . . . 18

3.2.2 Process virtual machine . . . 18

3.3 Ubuntu . . . 19 3.4 Package Manager . . . 19 3.4.1 Packages . . . 20 4 Analysis 21 4.1 Comparison . . . 21 4.2 Requirements . . . 22 4.3 Design . . . 22

4.3.1 Size and resource improvement . . . 22

4.3.2 Deployment . . . 23

4.3.3 Environment creation . . . 26

4.3.4 User interactions . . . 26

5 Results 28

5.1 Size and resources improvement . . . 28

5.2 Environment creation . . . 28

5.2.1 The Package Tab . . . 28

5.2.2 The Course Tabs . . . 29

5.2.3 Background mechanisms . . . 32

5.3 User interactions . . . 34

5.3.1 The chat . . . 34

5.3.2 The remote desktop . . . 35

6 Discussion 38 6.1 Communication . . . 38

6.2 Interactivity . . . 39

6.3 Course environment conflicts . . . 39

6.4 Virtualization . . . 40

6.5 Collaboration . . . 40

6.6 Encountered problems . . . 40

7 Future work 42 7.1 Size and resources improvement . . . 42

7.2 Environment creation . . . 42

7.3 User interactions . . . 42

7.4 Other tools . . . 43

Chapter 1

Introduction

Academic education is a combination of theory and practice. Students should have the opportunity to do practical work in laboratories to improve their skills and increase their experience. Unfortunately students and teachers may not always be physically present in the laboratory at the university or they may not be there at the same time. For these reasons a solution allowing students to work outside the university and at the same time staying in touch with each others and with teachers is needed. This solution should provide to the students everything they need to work as if they were at university. Nowadays new technologies and especially ones connected to the Internet are omnipresent. Since the World Wide Web can reach almost everyone on Earth, the computers’ field of activity has no limit. Computers can be relevant in lots of areas and one of them is education. This report aims to present my master’s thesis work with LiveLab at the Department of Computer and Information Sciences, Link¨oping Universitet. In the first place my task was to develop tools helping teachers to build their own environment in LiveLab. Indeed, the requirements for a course are different from another and it is inconceivable to create an environment that fits every courses. Then I should develop communication tools that allow users to be in touch with each others.

1.1

LiveLab

LiveLab is a tool created at Department of Computer and Information Sciences at Link¨oping University. It is a virtual machine running thanks to VMware Player with a Kubuntu Linux distribution as guest operating system. This means that while running the host (main) operating system as usual, a computer can run another operating system commonly refered as guest operating system. This way a user can run two completely different operating systems such as Microsoft Windows 1_{and Linux at the same time.}

1_{Microsoft Windows is the name of several families of software operating systems by}

Mi-crosoft.

1.2

Research question

What are the requirements and needs of a virtual laboratory? How can they be fulfilled? This thesis work focused on defining these requirements and then tried to fulfil them through the development of tools providing a better accessibility and interactivity between users.

1.3

Scenarios

By using LiveLab students do not have to set up a whole development envi-ronment on their own computer to do different laboratories. LiveLab contains the required softwares already installed and rightly configured. This way the students just have to install VMware Player to run the machine and then they can start to work on their tasks. This method aims to avoid configuration mis-takes or other problems that may occur when the students have to set their own environment up. As mentioned previously LiveLab is used at IDA only in three courses but this shall change in a near future and LiveLab shall be used in other courses and other departments. All these facts put together reveal lacks in LiveLab that I shall try to point out in this section through scenarios.

1.3.1

Deployment

Until now LiveLab’s deployment was relatively easy since one version only exists. The virtual machine file was available on the course home page and the students could download it. Since it shall be used in other courses, different versions with corresponding environments are required. On the other hand LiveLab’s basis is the Kubuntu Linux distribution and a few software applications only are added to create a course specific environment. That added to the virtual machine file size issue(2 GB2_{before decompression, 4 GB after) emphasize the}

fact that creating a full new version for each course seems unnecessary. Let us say that a student follows 3 courses using LiveLab, he should first download 6 GB and then once the decompression achieved it shall use approximately 12 GB of memory space on his computer. Moreover he should shutdown and start the corresponding virtual machine everytime he wants to work on another course. Because running three different virtual machines at the same time looks unconceivable. This reveals why a better deployment solution is required.

1.3.2

Environment creation

According to the deployment issue, having one version only for all courses seems to be a better solution. But the teachers in charge of these courses may be unexperimented in system configuration thereby creating or modifying an envi-ronment may not be easy to achieve. Moreover those envienvi-ronments should be easily available and updatable for the students.

1.3.3

Resources requirement

Since LiveLab is a virtual machine simulating a whole computer the resource requirement are high. Indeed the physical machine has to run in a usual way and moreover it has to run another full configuration at the same time. This means much more memory is required and the processor is highly roped in. Therefore a part of my task was to reduce the LiveLab’s resource requirements. Thus even a less powerful computer may run it.

1.3.4

User interactions

While working at the university during the laboratory sessions, the students can require the teacher’s help. Whereas if they are working outside the university or not during the laboratory’s time, they have to use solutions such as emails which presents obvious issues. First of all time before answer and then, the explanations have sometimes to be precise and weighty which may be difficult to acheive by email. But that is not all, laboratories may be group works thus the interaction between students is important too. It should be possible for the students to interact somehow to achieve their group works or help each others. Using an instant messenger is still possible but once again no direct help such as visual help is possible and the explanation accuracy issue remains.

Chapter 2

Related work

2.1

Virtual Laboratories

Link¨oping University is not the only university working on virtual laboratories. Numerous project exist at diferent universities. These pojects also aim to de-velop solutions providing outer working environments for students. [2, 9, 25, 23, 27, 21] For example three german universities developed a virtual laboratory providing a remote environment to set up prototype experimental environments [24]. This is achieved by using the technologies such as Java applets, Real-Time Transport Protocol (RTP) [6] and Apache server 1_{.[28] After a student}

has asked for a specific experiment he gets a user ID (identification) and a pass-word with which he can log into the server to book a time slot. The student can download the experiment instructions and at the experiment’s date he can connect to the experiment server through a common web browser. he uploads the prepared data onto the plant and starts the experiment. The student gets a live audio/video feedback of the experiment and can download the output data stored on the server. The figure 2.1 shows the communication protocol used by this virtual environment.

Figure 2.1: Example of a german virtual laboratory

1_{The Apache Server commonly referred to simply as Apache, is a web server notable for}

playing a key role in the initial growth of the World Wide Web.

The National University of Singapore (NUS) developed the same kind of laboratory bound to frequency modulation experiment [5]. The client/server architecture and Java applets are also used as you can see on the figure 2.3.

Figure 2.2: hardware architecture of the NUS’ virtual laboratory

Figure 2.3: software architecture of the NUS’ virtual laboratory These kinds of virtual laboratory present advantages and drawbacks: pros: • laboratory environment available everywhere an online computer is

avail-able

• software-installation-free client’s side in the case of the three german uni-versities

• applets are always up-to-date allowing a continuous improvement • preliminary prepared experiment avoiding technical issues cons:

• not fully platform independant due to the encoding technologies • some software installation in the case of the NUS’ solution

This approach appears not to be relevant in areas such as computer sci-ences since nothing else but a computer is required to perform laboratories. But it may be used in other areas such as mechanical or electronical engineer-ing. This project has been conducted about 8 years ago. During these past 8 years the technologies used in the project evolved a lot that is why it may be easier nowadays to set up this kind of environement, increase and improve the functionalities.

2.2

Collaboratories

The “Collaboratory”, term coined by William Wulf, is another kind of virtual laboratory [22]. This kind of system allows multiple users to work together on the same project. Using collaboratories allows the users to share resources as data, computational resource and perform a team work almost as if they were face-to-face. Four collaboratory categories have been identified:

• Peer-to-peer: The main points in this category are the shared instruments and raw, unanalyzed data. The remote access to these instruments and direct access to the data are important. As we can deduce the users work in the same field of research.

• Mentor-student: In this category it is common that the mentor prepares materials bound to the student. These materials may be live demonstra-tions, course lectures, different types of exercise for instance. The most important aspects here are the interactions between the mentor and the student. The mentor should be able to work in collaboration and interac-tively with the student. Another important aspect is the access to archival information as data, notes, results for both sides. Via this way the men-tor can correct the results for example and the student can revisit the materials.

• Interdisciplinary: In this category the users may work in different related areas. The direct access to instruments or row data, the interactive collab-oration are less important here. The main points are access to summaries and analyses and support for discussion.

• Producer-consumer: Here the output from a researcher or a research team becomes the input of another. The difference between the areas of the users is often wider. The most important is being able to provide and receive data.

The US Department of Energy (DOE) has started four collaboratory projects known as the Distributed Collaboratory Experiment Environments program (DCEE). As part of this program the Environmental Molecular Sciences Labo-ratory (EMSL) developed a prototype web-based collaboLabo-ratory called Core [22]. The Core provides differents tools to allow the users to work together. The tools include:

• Audio/Video conferencing • Chatting

• shared computer display and whiteboard • shared electronic notebook

• file sharing

• on-line instruments, computation, and visualization • web browser synchronization

Since LiveLab is designed to allow students to work in collaboration with the teachers, it belongs to the Mentor-student category. Knowing the main points of this category and the tools integrated in Core shall help to find the requirements for LiveLab.

2.3

Contribution

For this work I tried to find out and fulfil the different requirements of Live-Lab. I set up a whole new environment by changing the version of the Linux distribution previously used by LiveLab. I also developed tools allowing the students and the teachers to work in collaboration. I provide possible future work regarding what existed, what I made and what still lacks and is possible to achieve.

2.4

Method

To determine the changes that LiveLab required, I mainly interviewed teachers. I focused my questions on what was missing or had to be improved. But I also questioned them to know if they had solutions in mind. We discussed about these solutions together and tried to obtain the best of them. I also performed researches on the Internet about virtual laboratory environments. I studied the design of these environments and how they were working by reading documentation and articles. I tried to find out if they could help out in LiveLab’s improvement. I gathered all information I had and presented the solutions I came up with to the teachers, to collect their feedbacks and then improve these solutions if needed. These interviews appeared to be constructive since the teachers and I are directly concerned by LiveLab. Indeed they have to prepare laborotaries and thus create laboratory environments which I shall use as student. Having the target users being part of the development has been of great help. Thanks to that I could find solutions that seem to fulfil the expectations.

Chapter 3

Background

3.1

Virtualization

In computer sciences fields, virtualization refers to the gathering of all the tech-niques, hardware or software, that allow one machine to run several operating systems and/or software applications independently from each other as if they were running on seperate machines. [4, 29]

Concepts:

• hardware abstraction layer (HAL): An abstraction layer, implemented in software, between the physical hardware of a computer and the software that runs on that computer. Its function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware.

• host operating system: main operation system running on the machine • guest operating system(s): all other operating system running on the

ma-chine at the same time as the host one

• partitioning: isolation and/or sharing physical/application resources. Al-lows to isolate and share physical resources such as hard drives or appli-cation resources such as database.

• manageable images: start, stop, freeze, clone, save, restore, context saving, migration1_{. The virtual machines can be managed without affecting the}

other guest operating systems on the host machine. They can be stopped, their state can be stored and restored for recovery purpose for instance. Or the can be cloned during migration process.

• virtual networks : application layer network, inside the host machine only and between host and guest(s)

1_{Process of transferring data between storage types, formats, or computer systems. It is}

usually performed programmatically to achieve an automated migration, freeing up human resources from tedious tasks. It is required when organizations or individuals change computer systems or upgrade to new systems for instance.

Pros:

• optimal utilization of the resources of a machine group (spread the virtual machines on the physical ones depending on the load)

• installation, deployment and migration of virtual machine are easy. • Save and conserve (electricty power, maintenance, support or hardware

compatibility for instance)

• installation, tests, development are safer. Failure allowed without any threat for the host operating system

• secure or isolation of a network • simultaneous users isolation

• processing power dynamic allocation depending on the needs Cons:

• resources requirements, more memory is required which may induce slower execution

• harware compatibility, virtualization software can not virtualize unsup-ported hardware thus applications on the top of the virtualization can not use this hardware even if they support it.

• concentration risk, too many virtual machine on fewer physical machine may be problematic in failure situations

3.1.1

Different virtualization techniques:

Here are summerized some virtualization techniques [4, 12, 29]. Isolation

Software solutions (by oppostion to hardware solutions) allow to isolate appli-cation executions in different contexts or executions areas. This way you can run several instances of the same application even though only one instance is expected to run at a time per machine. Such a virtualized application runs in a small virtual environment containing the components needed to execute, such as registry entries, files, environment variables, user interface elements, and global objects. This virtual environment acts as a layer between the application and the operating system and eliminates application conflicts and application-OS conflicts. This solution achieves good performances but the vertual environ-ments are not fully isolated.

Examples: Linux-VServer [33], BSD Jail [13], Sun Microsystems Java Virtual Machine [8]

Figure 3.1: isolator architecture Kernel in user-space

With this solution the kernel is working as another application in a user-space of the host OS which has a kernel running on the host machine. The user-space kernel has its own user-space in which it controls its applications. This solution has a low performance rate because at least 2 kernels are stacked up it is used mainly for the kernel developement.

Figure 3.2: user-space kernel architecture

Examples: User Mode Linux (kernel running in user-space)[11], Cooperative Linux or coLinux (kernel cooperating with a Microsoft Windows host) [15] Para virtualization or hypervisor

A hypervisor is a lighter and optimized kernel build to run guest OS kernels only. These latters are optimized to run on the Xen 2 _{[34] architecture. The}

applications in user-space run on a two-kernels stack and the guest OS knows that they are virtualized. This solution seems to achieve better performances. Hardware virtualization

The virtual machine has its own hardware and allows a guest OS to be run in isolation. The virtualization may be inbuilt in the processor itself allowing the hardware to manage the memory accesses. This solution makes the software virtualization easier and improve the perfomances.

Examples: Mainframe VM/CMS [32], Sun LDOM [10], HP Superdome [14].

2_{Xen is a free software virtual machine monitor for IA-32, x86-64, IA-64 and PowerPC}

970 architectures. It allows several guest operating systems to be run on the same computer hardware at the same time

Figure 3.3: hypervisor architecture Emulation of simulation

The virtual machine simulates the complete hardware allowing an unmodified guest OS for a completely different CPU 3 _{to be run. This approach has long}

been used to enable the creation of softwares for new processors before they were physically available.

Examples: Bochs [3], PearPc [17]

Native virtulization or full virtualization

A virtual machine is a software running on a host OS. This software allows to run several guest OS. The machine virtualizes the hardware for the guests. The guest OS believes to be directly connected to the hardware. The solution may be mixed up with an emulator. In that situation the OSs are isolated but it has a high performance cost moreover if the processor has to be emulated.

Note: this is the kind of virtualization LiveLab uses through VMware solutions.

Figure 3.4: virtual machine architecture Examples: QEMU [20], Bochs, VirtualBox [31], VMware

3.1.2

Virtualization examples

The following examples illustrate applications of virtualization.

• Server consolidation: Virtual machines are used to consolidate many phys-ical servers into fewer servers which in turn host virtual machines. Each physical server is reflected as a virtual machine ”guest” residing on a vir-tual machine host system. This is also known as Physical-to-Virvir-tual or ’P2V’ transformation.

• Disaster recovery: Virtual machines may be used as ”hot standby” en-vironments for physical production servers. This changes the classical ”backup-and-restore” philosophy by providing backup images that can ”boot” into live virtual machines capable of taking over workload for a production server experiencing an outage.

• Testing and training: Hardware virtualization can give root access to a virtual machine. This may be relevant in situations such as kernel devel-opment or operating system courses.

• Portable applications: Certain application configuration mechanisms such as the registry on the Microsoft Windows platform lead to some issues in portable applications creation. For example, many applications cannot be run from a removable drive without installing them on the system’s main disk drive. This is a particular issue with USB4_{drives. Virtualization can}

be used to encapsulate the application with a redirection layer that stores temporary files, Windows Registry entries, and other state information in the application’s installation directory.

• Portable workspaces: Recent technologies have been using virtualization to create portable workspaces on devices like iPods5 _{and USB memory}

sticks. These products include:

– Application Level (Thinstal) which is a driver-less solution for run-ning ”Thinstalled” applications directly from removable storages with-out system changes or needing Admin rights.

– OS-level (MojoPac, Ceedo, Aargo and U3) which allows end-users to install some applications onto a storage device to use on another PC. – Machine-level (moka5 and LivePC) which delivers an operating sys-tem with a full software suite including isolation and security protec-tions.

3.2

Virtual machine

A virtual machines (VM) is described as software implementation of a machine (computer) that executes programs like a real machine [29]. Virtual machines

4_{Universal Serial Bus is a serial bus standard to interface devices. USB was designed to}

allow peripherals to be connected using a single standardized interface socket and to improve plug-and-play capabilities by allowing devices to be connected and disconnected without re-booting the computer

can be separated in two major categories based on their use and degree of corre-spondence to any real machine. A system virtual machine provides a complete system platform supporting the execution of a complete operating system. In contrast a process virtual machine is designed to run a single program which means that it supports a single process. An essential characteristic of a vir-tual machine is that the software running inside is limited to the resources and abstractions provided by the virtual machine.

3.2.1

System virtual machines

System virtual machines (sometimes called hardware virtual machines) allow multiplexing the underlying physical machine between different virtual machines each running its own operating system. The software layer providing the vir-tualization is called a virtual machine monitor or hypervisor. A hypervisor can run on bare hardware (Type 1 or native VM) or on top of an operating system (Type 2 or hosted VM). The main advantages of system virtual machines are:

• multiple OS environments can co-exist on the same computer in strong isolation from each other;

• the virtual machine can provide an instruction set architecture (ISA) that is somewhat different from the one of the real machine.

Multiple virtual machines each running their own operating system are fre-quently used in server consolidation where different services that used to run on individual machines in order to avoid interferences are instead run in separate VMs on the same physical machine. This use is frequently called quality-of-service isolation (QoS isolation). The guest operating systems do not have to be all the same, making it possible to run different ones on the same computer (e.g. Microsoft Windows and Linux or older versions of an OS to support soft-ware that has not yet been ported to the latest version). The use of virtual machines to support different guest operating systems is becoming popular in embedded systems; a typical use is to support a real-time operating system at the same time as a high-level OS such as Linux or Windows. Another use is to sandbox6an OS that is not trusted possibly because it is a system under devel-opment. Virtual machines have other advantages for OS development including better debugging access and faster reboots.

3.2.2

Process virtual machine

A process VM (sometimes called an application virtual machine) runs as a com-mon application inside an OS and supports a single process. It is created when that process is started and destroyed when it exits. Its purpose is to provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system and allows a program to execute in the same way on any platform. A process VM provides a high-level abstrac-tion (compared to the low-level ISA abstracabstrac-tion of the system VM)- that of a high-level programming language. This type of VM has become popular with the Java programming language which is implemented using the Java virtual

6_{A sandbox is a testing or virtual environment that isolates untested code changes and}

machine. Another example is the .NET Framework7_{which runs on a VM called}

the Common Language Runtime.

3.3

Ubuntu

Ubuntu is a predominantly desktop-oriented Linux distribution based on Debian GNU/Linux but with a stronger focus on usability, regular releases, and ease of installation at the expense of platform diversity. It emphasises accessibility and internationalization to reach as many people as possible. Besides standard system tools and other small applications, Ubuntu comes installed with the following software: the OpenOffice.org productivity suite, the Internet browser Firefox, the instant messenger Pidgin (formerly known as Gaim) and the raster graphics editor GIMP. Ubuntu offers a fully featured set of applications that work straight from the standard install but nonetheless fits on a single CD. The Ubuntu live CD requires 256 megabytes of RAM 8 and once installed on the hard drive, Ubuntu needs four gigabytes of memory space. There are several variants of Ubuntu, official or not. The three most famous official ones are:

• Kubuntu: a desktop distribution using KDE9 _{rather than GNOME}10

• Xubuntu: a ”lightweight” distribution based on the Xfce11_desktop

envi-ronment instead of GNOME

• Edubuntu: a distribution designed for classrooms using GNOME

3.4

Package Manager

The package managers allow users to install, update or remove applications simply and properly by downloading packages from repositories. A package is a archive (compressed file) containing files, information, and procedures neces-sary to install an application. A repository is a server on which the packages are stored. When a user install an application the package manager will basically look on which repository the package is available, download it and install it. It will also install the package’s dependencies. Indeed it is common that to install a package other packages have to be installed first. For instance to install an application made with the python language python has to be installed first, most of package managers handle this aspect. All the information about avail-able packages are stored in local files on the user’s machine. These information are commonly referred as the APT’s cache and may be update by scanning repositories. Repositories’s adresses are stored in a specific system file: the APT

7_{The Microsoft .NET Framework is a software component that is a part of Microsoft}

Windows operating systems. It has a large library of pre-coded solutions to common program requirements, and manages the execution of programs written specifically for the framework

8_{Random access memory is a kind of computer data storage.}

9_{KDE (/K Desktop Environment/) is a free software project which aims to be a powerful}

system for an easy-to-use desktop environment.

10_{GNOME is an international effort to build a complete desktop environment entirely from}

free software.

11_{Xfce is a free software desktop environment for Unix based platforms, such as GNU/Linux,}

Solaris and BSD. It aims to be fast and lightweight, while still being visually appealing and easy to use.

sources file. All these actions may be done via graphical user interfaces or via command lines.

Graphical User Interfaces:

• Gnome-App-Install: Most likely the simplest package manager.

• Synaptic: May look more complicated, it however allows a more advanced package management than Gnome-App-Install

• Adept: Default Kubuntu’s package manager

• gdebi: Meant to install packages from files (.deb extension) downloaded on Internet for instance.

Command lines tools:

• apt-get: Advanced Packaging Tool is a group of tools used through com-mand lines such as:

– to install a package: sudo apt−get install <package name> – to remove a package: sudo apt−get remove <package name> – to update the packages information: sudo apt−get update

• Aptitude: Barely identical as apt-get, it however has a different package management.

– to install a package: sudo aptitude install <package name> – to remove a package: sudo aptitude remove <package name> – to update the packages information: sudo aptitude update – to run the interactive mode: sudo aptitude

• dpkg: Another command line package manager but does not handle pack-age dependencies. Its GUI is gdebi.

– to install a package: sudo dpkg -i <package file> – to remove a package: sudo dpkg -r <package file>

3.4.1

Packages

The package managers presented in this section are build to manage DEBIAN packages (.deb file extension). But these latters are not the only type of existing packages. Other package systems exist for other Linux distribustions, systems such as RPM, TGZ and SLP. These systems are not handled by Ubuntu. How-ever a package belonging to one of these system can be converted to a DEBIAN package through a software called “alien” [16].

Other famous package formats exists. They are mostly used to create archive files to gather several files in one or to compress files. These archives may be files with extensions such as .TAR, .TAR.GZ, .ZIP, .RAR. These files can be easily extracted using the corresponding sofware but are not made to install applications through package managers.

Chapter 4

Analysis

4.1

Comparison

To have a better understanding of why LiveLab exists and why it is has been made like that I will try to compare it with other existing virtual laboratory environments.

Several very different kinds of virtual laboratories exist. These environments are closely related to their area of application. For example it should be unfeasible to use LiveLab instead of one of the virtual laboratories described in section 2.1 and vice-versa. But it may be possible to use them together. These virtual laboratories present several differences compare with LiveLab. The main one is their task-oriented aspect. That is to say they have been designed to perfom specific tasks whereas LiveLab can carry out everything that a computer does. This may appear as a limitation but this difference is directly related to their areas of research. LiveLab has been designed to carry computer sciences lab-oratories out. That is why a whole computer is required. Whereas the other virtual laboratories have been designed for mechanical or physical researches. Thus they have been made to perform laboratories which require physical in-teractions with an environment or objects. In that way LiveLab seems better because it should easier to upgrade it; by just installing new softwares a bunch of new experiments may be performed. For the task-oriented laboratories, if a new laboratory needs to be created, new applets have to be developed and set up which may cost time and resources. Another aspect is that LiveLab could integrate the other laboratories but the opposite is not possible, in that sense LiveLab is more open to perform new tasks than the other laboratories.

That is the main difference and the best advantage of LiveLab but this latter has drawbacks too. It is heavier, requires more resources and is less portable. LiveLab is not web-based thus you need to use the computer on which it has been installed to do your tasks or consult your results. We may imagine the user saving the virtual machine file on an external disk but it seems less convenient. In that point the other virtual laboratories appear to be better than LiveLab because they can be used everywhere a computer connected to the Internet is available.

This Internet dependancy may be seen as a drawback compare with LiveLab which does not strictly requires a Internet connection to work. But numbers of

resources such as documentations, course web-pages are available on Internet only. Moreover during my work I never considered developing offline solutions, thus the tools I developed require an Internet connection. That is why the Internet connection appears not to be a relevant comparison point.

It is possible of course to compare LiveLab with a real laboratory. We can point out the differences between performing laboratories at the university and performing them somewhere else. The first difference poping up is presence of teachers or group mates if the laboratory is a group work. Achieving group work may be easier while all group members working at the same place. Whether it is for sharing ideas or getting someone’s opinion about the work in progress, the communication, oral or visual, is direct and instantaneous. Then comes the resources availability. All required softwares, applications are present and already set up on university computers. Thus no time is lost for installation pro-cesses and set up mistakes are avoided. These seem to be the major differences between a real laboratory environment and a virtual one such as LiveLab.

To conclude I will compare LiveLab with the Collaboratories described in section 2.2. These virtual laboratories are designed to favour team work or collaboration, LiveLab does not. Since laboratories may be team works and often are binomial work, the fact that LiveLab does not have adequate tools could to be problematic.

4.2

Requirements

As I said before when I started my work the virtual machine file was heavy. That is why a part of my task was to reduce the size of this file but not only. Since it runs a full virtual computer, LiveLab is a big resources consumer. This was the second aspect that I had to reduce. The other requirements are the ones pointed out with the scenarios in section 1.3.

4.3

Design

4.3.1

Size and resource improvement

To improve the resource requirements while keeping the same functionalities another operating system appeared necessary. The system had to provide the same possibilities than the previous one, be free, as easy to use and of course compatible with the virtualization tools used. That is why Xubuntu Linux distibution has been chosen.

Arguments

The Xubuntu Linux distribution is a lightweight distribution comparable to the Kubuntu one. Xubuntu uses the Xfce desktop environment instead of KDE. The system requirements for Kubuntu are at least 256MB of RAM and 3GB of available hard drive space whereas the Xubuntu’s ones are 192MB of RAM and 1.5GB of free space on your hard disk.[30] These data show that Kunbuntu requires about twice more space and resources than Xubuntu. Since it is a Linux distribution, Xubuntu provides the same functionalities as Kubuntu, is

free and the desktop environment is as easy as the Kubuntu one. Thus all the requirements are fulfilled.

Alternatives

Regarding all the requirements no other alternative has been found. The being-free argument set aside all the operating systems such as Microsoft Windows or non-free Linux distributions. Of course other free Linux ditribution exist but their accessibility seem lower. Since the target users may be unfamiliar with computers this latter aspect is important, that is why Xubuntu seems to be a better alternative.

4.3.2

Deployment

The deployment has to be easy, as fast as possible and should be the same for all courses using LiveLab. Thus the deployment shall remain approximately the same. It means that the students will still have to download the LiveLab file and install the VMware Player to run it. But this file will contain a basic version of LiveLab and packages corresponding to the courses shall be available through the APT system. These packages shall contain the files and softwares required for the corresponding course.

Arguments

Traditional laboratories may require materials such as lectures, documentations, laboratory instructions and if necessary software applications. These materials may be given directly by teachers as printed documents or through Internet on the course home pages. Obviously the paper solution cannot be applied in remote laboratories. The second solution might been used but presents other issues. For example, if laboratory material contains applications to install, the installation process may be problematic for some users. To install applications on Xubuntu as almost all others Linux distributions, the user can use one of the package managers described in section 3.4. As explained these systems allow to install applications by copying files available on repositories. Some of these tools are already present in Xubuntu, relatively easy to use and reliable. Since a course is usually composed of several laboratories, the materials may require to be updated. The Update-Manager tool present in Xubuntu periodically up-date package information and inform the user about available upup-dates on APT repositories. Thus notifications about the course updates are sent automati-cally to the users through the system itself (fig. 4.1). Allowing students to keep their materials up-to-date (fig. 4.2) and download new materials or install new applications if required. Once the course is completed the uninstallation is as easy as the installation process.

Alternatives

To reduce intermediate operation such as download, installation and convertion, the packages presented in 3.4.1 have been set aside because whether there are not handled by Xubuntu or are not made to install applications like DEBIAN packages are. Then two main package managements remain: the APT’s one and the Aptitude’s one. As exposed in section 3.4 almost all existing tools use the

Figure 4.1: Available updates notification

APT management. That is why the Aptitude’s one has not been chosen. Since tools already exist and their development are carried along Kubuntu’s, for now no valuable reason to use something else has been found. Still, it is possible not to use the APT system by providing resources on web-pages and ask the users to install them by themselves. But this may lead to issues such as missing updates or installation mistakes which could be avoided by using the existing tools.

Tools such as Gnome-App-Install, Synaptic or Gdebi may be used to install packages on Xubuntu.

4.3.3

Environment creation

A course environment is usually made of course materials such as lectures, lab-oratory instructions and if necessary software applications. All these have to be put together in packages that the students will download from repositories through the APT system. To create such packages, it is necessary to create specific directories and files, put the course files in these directories, run shell commands then upload the newly created package on the repository. It should be easy to add or remove files or softwares from the packages. Thus to create a software able to carry all these actions out looked like a good alternative. The python language has been chosen.

Arguments

The actions listed before may be problematic to perform for common users. That is why a tool with a graphical user interface (GUI) has to be implemented. Python provides everything necessary to build GUIs, is platform independent and has efficient tools for strings manipulations.

Alternatives

Since it is a specific requirement usefull in LiveLab only no alternatives exists. I could have chosen other language such as Java, C++ for example but I have chosen python because the string manipulations, file parsing and system libraries appeared as efficient and sometimes even more efficient. Moreover runing shell commands or script with Python is easier than with Java which sometimes does not seem to work for unknown reasons.

4.3.4

User interactions

The collaboration between teachers and students is the heart of laboratories but not only. As said previously the collaboration between students is also impor-tant. That is why keeping these links matters. The users should be able to communicate in live with the each others. A student could do a visual demon-stration to a teacher as if the two parties were in front of the same computer. To achieve that instant messaging and remote desktoping have been chosen. These two functionalities shall be gathered in a tool developed in Java. The XMPP

1 _{[19] protocol or Jabber is used for instant messaging and the VNC one for}

remote desktoping. Arguments

Instant messaging resolves the emails’ time-before-answer delay issue. Several protocols allow instant messaging and many clients are available for free but Jabber appeared to be one of the most advanced open-source protocol available. Since the Jabber community is huge, libraries, documentations or helps are

1_{Extensible Messaging and Presence Protocol is an open, XML-inspired protocol for}

near-real-time, extensible instant messaging and presence information (a.k.a. buddy lists). It is the core protocol of the Jabber Instant Messaging and Presence technology. The protocol is built to be extensible and other features such as Voice over IP and file transfer signaling have been added.

easy to find. I have chosen Java as programming language because one of the most developed library is the Smack[18] library available in this language only. Concerning the remote desktoping several tools and protocols exist too. VNC is one of the most common and used over the Internet and already present in Xubuntu. I decided to develop a new application because no one gathering both features could be found. Moreover it should be easier to add LiveLab specific features for future applications.

Alternatives

Becoming more and more used over the Internet the VoIP 2 _{could have been}

used too. Because of a lack of time this solution has been set aside. Nevertheless the Smack library has been chosen because it supports the VoIP and lots of free VoIP clients are available on Internet.

2_{Voice over Internet Protocol is a protocol optimized for the transmission of voice through}

the Internet or other packet switched networks. VoIP is often used abstractly to refer to the actual transmission of voice (rather than the protocol implementing it).

Chapter 5

Results

This chapter will describe the results of my work and explain how the tools I developed work.

5.1

Size and resources improvement

As described in subsection 4.3.1 the memory space required for Xubuntu is half Kubuntu’s. This is because Xubuntu aims to provide a lightweight environment for less-powerful machines. That is why it includes less applications. Thus the new version of LiveLab using Xubuntu instead of Kubuntu is lighter as expected. The virtual machine’s file is about twice smaller. Concerning the resources consumption no significant difference has been noticed.

5.2

Environment creation

As explained in section 4.3.3 a course environment is made of resources such as documentations, course lectures, laboratory instructions. But it needs specific applications to perform laboratories. This tool aims to allow a user to create packages and make them available to students on repositories. Thus the students may install a new course environment by using the package managers. The tool is called LLCourseManager, its package (LLCourseManager.deb) is available on a repository thus by using the APT system it can easily be installed on any version of Linux.

5.2.1

The Package Tab

When the application starts the first tab displayed contains two lists:

• the categories (left): all the existing categories that the packages belong to

• the packages (up-right): all the packages corresponding to the selected category

By clicking on one of the category the package list is updated with the corre-sponding packages. The packages list has two columns: the first is the package’s

name and the second a short description of the package. When a user clicks on a package in the list a full description of the package is displayed underneath the list.

Figure 5.1: LLCourseManager main window

The user can see what files the package contains using the Properties button in the tool bar.

It is also possible to search for a package. When a user clicks on the Search button a dialog window pops up. The searched key word has to be entered in the field. To include the package description in the search the check box has to be ticked.

When the search operation is done, the category list is filled with the search history thus the user does not have to do twice the same research. The three buttons underneath the category list allow the user to switch the content of this list.

• Categroies: the existing categories • Search: the search history

• Installed: the installed packages on the system

5.2.2

The Course Tabs

To create a new course environment the user has to click on the New button. A dialog box appears asking for information:

Figure 5.2: package’s file list

Figure 5.3: search dialog

• Course Code: the course code

• Name: the teacher’s name in charge of the environment • Email: the teacher’s email

• JID: the teacher’s Jabber address

• SSH @ repository: the location of the course repository (ex: denmo542@astmatix.ida.liu.se/home/repository)

Once the user has entered the information a new tab corresponding to the code is added to the main window. A course tab contains three parts:

• Desktop (up-left): display a tree with the files located on the Desktop • Course (up-right): display a tree with the files contained in the course

directory which is in the home directory

• Packages (bottom): a list of the packages that the course requires

When the teacher wants to add files on the Desktop or in the course directory, he just has to drag and drop them on wanted folder in the corresponding tree. He can remove files by selecting them and pressing the Delete button. To add packages up to a course the user has to right-click on the package in the list then select the “Install in...” option and finally the course code. The package name will appear in the package list in the corresponding course tab.

When the user decides to save the course environment by clicking the Save button, the course information are displayed to confirm them and if the user validates the package is build and uploaded on the repository. From that time the package is available through the APT system.

5.2.3

Background mechanisms

I will now explain the machanisms the user do not see. This to understand how this application works

The package listing

Several shell commands allow to list the existing, available and installed pack-ages and of course to get information about these packpack-ages. To create the package list the application sends the results of such commands into text files, parses these files and then dipslays the data. For example the command:

apt-cache dumpavail

displays all the packages and their information available in the APT’s cache. The information about a package look like this:

Package: firefox

Status: install ok installed Priority: optional

Section: web

Installed-Size: 28704

Maintainer: Ubuntu Core Developers <ubuntu-devel@lists.ubuntu.com> Original-Maintainer: Eric Dorland <eric@debian.org>

Architecture: i386

Version: 2.0.0.11+0nobinonly-0ubuntu0.6.10 Replaces: mozilla-firefox

Provides: www-browser

Depends: fontconfig, psmisc, debianutils (>= 1.16),... Conflicts: mozilla-firefox (<< 1.5.dfsg-1)

Size: 9269320

MD5sum: 3aebff0469d7d9adc0e98e552a9e9f40

Description: lightweight web browser based on Mozilla

Firefox is a redesign of the Mozilla browser component, similar to

Galeon, K-Meleon and Camino, but written using the XUL user interface language and designed to be lightweight and cross-platform.

This browser was previously known as Firebird and Phoenix. The package tree structure

To create a package for the APT system (also called DEBIAN package) a specific structure has to be followed (fig. 5.6):

Figure 5.6: Debian Package tree structure

The name of the root folder must be the name of the package, here by convention I have chosen the course code as package names. Then the DEBIAN folder contains the package’s control file. This file contains the information about the package as they are displayed in 5.2.3. Other files may be added to perform specific action before and after the package is installed or removed. Then at the same level as the DEBIAN folder any folder corresponding to the Linux file system can be created. Here I use the /home/student/ folder which represents the student’s Home folder. In that folder I use the Desktop folder to place files on the student’s Desktop and a folder named with the course code. These two folders are the trees displayed in a course tab in the application. If a user wants to put some files into the folder /usr/lib/ by instance he must create a folder /usr/lib/ at the same level as the DEBIAN one. Thus when a user drag and drop files on a course tab these files are copied at the corresponding location in the package structure.

Packaging and upload

To make a package available it has to be saved. At that time the application creates the packages thanks to the following command:

dpkg-scanpackages packages override | gzip > Packages.gz

The override file usually contains information about the repository’s packages but here it does not since it is not mandatory to work only its timestamps

1 _{must be updated. The Packages.gz archive contains the list of all available}

packages on the repository and their information. These two files are updated at the same time the course package is built. Then these two file and the package file are uploaded on the repository by using the scp (secure copy) command through the SSH 2 _{[7] protocol. At that time the package shall be available for}

the students on the repository. Installing a course package

As said in section 3.4 the repositories adresses are stored in the APT’s sources file. To update this file the root access are required and it the address has to be added correctly (i.e. follow address format conventions). To avoid any mistakes a feature has been added to the web browser Mozilla Firefox. Thus teachers shall add pre-formated web links containing the repository address up to the course pages. Then students just by clicking these links will add repository addresses up to the APT’s sources list. From that moment the student can install the courses available on the newly added repository. To do so students will only have to run the command:

sudo apt-get install cource code

and the course environment will be installed on their computer.

5.3

User interactions

This chat application, LBChat, shall be installed by default on LiveLab this way the users do not have anything to do to use it but running the command LBChat

5.3.1

The chat

The application looks like a basic instant messaging chat. When it starts the connection window appears and asks the user to fill the fields with his informa-tion (login, password, XMPP server and status). If the user does not have an XMPP account yet he can create one by clicking the “create a new account” link then a dialog window will popup and asks the user for the same information as for the login step. As soon as the account is created he can log into the chat.

The chat window is basic: • the chat’s output tabs (up left)

• the chat’s input field to enter text (bottom left) • the user’s contact list (right)

By double clicking on of his contact, a new chat tab will appear and the user shall be able to chat with his contact.

2_{Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure}

channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.

Figure 5.7: LBChat’s connexion frame

The contact list (entries, groups) can be managed with the “contacts” menu or thanks to the right click popup menu directly on the list. The user can also manage his account features (nickname, password...) with the “account” menu. Files may be sent by selecting “Send File” in the “Actions” menu. The trans-fer progress will be displayed underneath the input field. Another interesting feature is the “Teachers JID” option in the “Actions” menu. When the stu-dent installs a course which has been created with the LLCourseManager the teacher’s Jabber address (JID) will be stored in a file if the teacher provided one. When the student uses the “Teachers JID” option the list of all stored teacher’s JIDs will be displayed and he can easily add them up to his contact list.

5.3.2

The remote desktop

This feature was the main reason to develop a new Jabber chat rather than to use an existing one. The aim was to provide the possibility for students to start VNC sessions with teachers by performing a simple action in the chat. I shall explain how it is achieved, but it is necessary to understand a few concepts of XMPP and VNC first. XMPP protocol uses server communication, it means all messages go through the server first and then are sent to the correct user. Thus the IP3 _{addresses are never exchanged but in one situtation: the file transfer.}

Indeed the file transfer is a direct communication thus when a user wants to send a file, a request is sent first and if the request is accepted the IP address shall be communicated.

3_{Internet Protocol is a data-oriented protocol used for communicating data across a}

Figure 5.8: LBChat’s main frame

Why do we need the IP address? Because it is the only way to start a VNC session. Usually a user starts a VNC session by running a command which looks like: vnc Targeted-Computer-IP-Address or through a GUI which requires the IP address too. But here it is slightly different, indeed teachers shall start to listen to the incoming VNC request and students shall send VNC “reverse” requests.

Now I shall describe the step to establish a VNC session. Teachers do not know students IP addresses and we can not ask any student to find his IP address by himself, that is why a background method has been developed. When a user right-click on a contact within his contact list, the “Raise Hand” option appears. Selecting this option shall send a flag message with a specific subject and specific body. Since the application filters the incoming messages flag messages shall be intercepted and understood as “Raise Hand” requests. A question dialog window shall ask to the recipient if he accepts the request or not. If he does, another flag message containing the teacher’s IP address shall be sent back and a “listening VNC session” started. Once the IP address received, the “reverse VNC request” shall be sent and the session start automaticaly. This schema has been inspired from the 3-way handshake for TCP connections establishment[7].

Chapter 6

Discussion

6.1

Communication

The communication is a major aspect of laboratories, especially in team work wich is often the situation in Link¨opings Universitet laboratories. It helps to develop skills for solving problems in a team [26]. Moreover it has been shown that virtual classrooms promote discussion between participants [1]. That is why the focus of my thesis was to improve the communication means between LiveLab users. Thus the two tools developed for this purpose aim to provide communication means previously non-existant. These means should provide an environment as close as possible from traditional laboratories to avoid any inconvenience while swtiching between traditional and virtual laboratories.

The very basic of laboratories is teachers preparing exercises for students and then students doing these exercises. These exercises may be of different types and require different kinds of material. Thus the very first communication line is between teachers and students. Teachers should be able to provide prepared works, corresponding materials and updates if needed. As described in 5.2 the environment creation tool allows teacher to gather all required laboratory materials in packages and to make these packages available on the APT package system.

Then students shall be informed of the available packages through this very same system thanks to package managers and update notifier.

Then comes another important communication link between laboratory par-ticipants. During a traditional laboratory participants, students as well as teach-ers, communicate between each others. It can be for several different reasons such as requiring assistance, sharing opinions, demonstrating results. All these reasons allow laboratories to be performed and thus make the communication between participants essential. Thanks to the chat application developed, users can talked to each others through the text-messaging chat and share their envi-ronment display through the remote desktop. Thus students can achieve group work and perform demonstration for teachers almost as if they were in a labo-ratory at the university.

Breaking the comminication links would have make remote laboratory envi-ronments less efficient and further from a traditional environment. That is why while developing the tools I kept in mind to save these links and make them as

simple a possible. Thus the communication link between teachers and students is not direct anymore as in traditional laboratory but still remains.

6.2

Interactivity

Another important aspect I tried to improve in LiveLab is the interactivity. Keeping the communication links is not enough, they should be as simple and intuitive as possible. That is why using Mozilla Firefox to run scripts by click-ing on specific links appeared a good way of improvclick-ing this interactivity. For instance, when a teacher gives laboratory materials to students it is through paper documents or files on web pages. This way it is very easy for students to get these materials, that is why I wanted to keep this easiness for such ba-sic tasks. Thus when a student installs a course package for the first time, he may not use the package managers through command lines or even through their graphical user interfaces but he can simply click on a internet link. This solutions may be applied to different other situations that previously required several actions from the students, situations such as laboratory registrations or hand laboratory reports in.

6.3

Course environment conflicts

Even if using the packages system to install course environments appeared to be a good solution, some issues remains. One of them is the conflicts between the course environments. Let us say that a course needs a version of an application older than the latest one while another course needs the latest version. If the latest is installed first, the package managers shall not install an older since the latest is already present. This could lead to some issues but it does exist solutions to force installations. In the case of conflicts becoming too important to allow different environments to coexist, having different versions of LiveLab on the same computer may be the only solution. Nowadays hard drive capacities are big enough to support it, it is like having several games installed or movies saved for example. Since students should not work on all different courses at the same time stopping and starting these different version of LiveLab is almost like stopping and starting any other application. Another point is that teachers may prefer work inside LiveLab directly instead of preparing the packages outside or student may prefer to have different version for each course to be sure to avoid any conflict. Because of these issues we may reconsider the package solutions but in the multiple version solution, the file size may be seen as an issue for dowloading processes. It may be difficult to download a barely 1GB file with low speed connections. A file difference solutions has been also discussed. Students would have all their documents on their university folder and use the mounted file system to use them. Thus whenever the system configuration is changed inside LiveLab virtual machine’s file, students shall perform a file difference and download this difference only. Enven though the complexity of the virtual machine file may be problematic to perform this difference, this way is worth to explore.

6.4

Virtualization

Before, I could not imagine that virtualization was so widly used in information technologies and computer sciences. Now that I have a better view on how virtualization is used, its purposes and its numerous advantages, I understand why. Indeed virtual machines seem to be one of the best solutions to create virtual/remote environments. Virtualization allows isolation from surrounding environments and thus provide a certain level of safety for these latters. More-over using virtual machines allow to run guest environments on very different kinds of host and thus provides platform independance. Thus virtual environ-ment are relatively safe and portable which seems to be two critical points in virtual laboratories development. These latters points make the use of virtual-ization through a virtual machine such as LiveLab, a very convenient solution. Students can use LiveLab whatever the main operating system is and do not risk to damage it if any wrong manipulation is performed into LiveLab.

6.5

Collaboration

All along my work I discovered the virtual laboratories environments. These en-vironments allow users to achieve such great things which could not be possible without the current technologies. They break walls between poeple and allow them to work together without geographical or time issues. The user interactions have almost no limits but the hardware limitations. For me, the main advantage of virtual remote environments is the collaboration. Collaboration allows for in-stance to share unique or expensive equipment for inin-stance, or a pool of data or experiments comming from a wider range of laboratory resources. Unfortu-nately those environments often are project conducted by independant reseach groups and use of software of hardware of other universities for instance, is not contemplated enough. Thus, until now no methodology or standard to develop networks of virtual/remote laboratories existed[21]. Although, I think that in a very near future, virtual environments could be revealed as new education or research paltforms and their utiliszation proportions and area applications will keep increasing. LiveLab is not designed to be a collaboratory but since we try to widen its field of activity, developing tools allowing collaboration such as the ones described in 2.2, might be the next step in LiveLab evolution.

6.6

Encountered problems

The main technical issue I met was the IP addresses communiction for remote desktoping. VMware Player has two network configurations which allow the virtual machine to be connected with external networks as Internet. The first one is the “Bridged” configuration. Basically the virtual machine will try to get connected on the same network as the host machine and get an IP address from this network thanks to the network’s DHCP 1 [7]. If I use this method in Link¨oping Universtiy the virtual machine will not be autenticated by the university intranet and then will not be able to reach external networks. The

1_{Dynamic Host Configuration Protocol is a protocol used by networked devices (clients)}

to obtain various parameters necessary for the clients to operate in an Internet Protocol (IP) network.

second configuration is the “NAT” one, in this case VMware Player provides a local IP address to the virtual machine and manage the traffic through the host machine IP address. Since this IP address is not visible outside the local network, it is not possible to use it to start a classic VNC session. Thus students had to start the sessions to open the communication channel which shall be used by teachers. That is why the VNC reverse connection has been used. Unfortunately this IP issue remains if the teacher also uses LiveLab.

Chapter 7

Future work

Here I will talk about the possible future work that may be achieved for LiveLab

7.1

Size and resources improvement

As explained in section 5.1 no significant difference concenrning the resources consumption has been noticed. A study could be conducted to find out if Xubuntu’s LiveLab version actually achieve better results in matter of resources uses or if not and then maybe to find a solution improving this aspect of LiveLab.

7.2

Environment creation

The environment creation tool may be improved in some ways. For now there is no possibilities to configure in a specific way the softwares required for a course and clone this configuration on the students computers.

7.3

User interactions

As I said before, the VoIP has not been implemented in the communication tool, it may be interesting to integrate this feature in it.

Since students mail accounts are Google GMail accounts, they can use Google GTalk which is a XMPP text messaging system with the very same user ID as their mail one. This way a link between LBChat and students university account may be created avoiding new registrations. We can even think about a system bound to the laboratory registration system to create contact lists with these IDs.

The feature added in Mozilla FireFox allowing to add repositories addresses up to the APT’s sources list only by clicking a link may be widen to other actions. We can think about action such as adding contact up to a buddy list in a chat, simplified laboratory registrations or anything previously requiring users actions could be replaced by a click.

7.4

Other tools

We have seen in the Core poject some tools that may be relevant in a virtual laboratory. Tools such as:

• shared whiteboard: to share information between users

• global synchronization: this way a manipulation performed on a master version of LiveLab (teacher) is echoed on the slave ones (students) • on-line instruments, computation, and visualization: using java applets as

described in section 2.1 to perform laboratories in areas requiring other equipments than a computer.