Using coLinux to Provide a Linux Environment on Windows PC in Public Computer Labs

Hideo Masuda Kyoto Institute of Technology

Matsugasaki, Sakyou, Kyoto 606-8585, JAPAN

+81 75 724 7956

h-masuda@kit.ac.jp

Akinori Saitoh Tottori University of Environmental Studies Wakabadai-kita, Tottori 689-1111, JAPAN

saitoh@kankyo-u.ac.jp

Michio Nakanishi Osaka Institute of Technology

Kitayama, Hirakata, Osaka 573-0196, JAPAN

naka@is.oit.ac.jp

Seigo Yasutome Osaka Institute of Technology

Kitayama, Hirakata, Osaka 573-0196, JAPAN

yasutome@is.oit.ac.jp

ABSTRACT There are many requests from teachers to computer lab management staff in universities. The most annoying one is that both the Windows and Linux environment are required. To satisfy such a request, a dual-boot system is widely used. But on a dual-boot system, students must wait for minutes to switch between Windows and Linux. And management staff has to repeat the boot and shutdown process to apply patches to both operating systems. To provide both operating systems’ environment simultaneously, we have decided to use coLinux to run Linux as a Windows application, and installed it in our PC classroom. coLinux, Cooperative Linux, is an open-source, lightweight solution, as compared to full virtualization techniques such as VMware or Virtual PC. Cygwin could be another solution, but it has some restrictions against the full capability of Linux such as process management. coLinux enables both native Linux applications and Windows applications to run simultaneously on the screen. Our solution also avoids incompatibility problems that sometimes occur between Microsoft Office on Windows and Office suites on Linux.

Categories and Subject Descriptors D.4.7 [Operating Systems]: Organization and Design

General Terms

Design, Management, Experimentation.

Keywords Windows and Linux, dual-boot system, coLinux.

1. INTRODUCTION There are many university computer laboratories that provide a collection of Linux and Windows dual-boot computers to support a wide variety of computing needs, because there are many subjects from computer literacy course in general education curriculums to specialized computer science subjects [1]. At Kyoto Institute of Technology, applications that run only on Windows such as CATIA (CAD tool) and CAChe (3D modeling tool for Chemistry) are required for architecture and design subject., At the same time, a Linux operating system environment is required for the computer science subjects and embedded system development subjects which use gcc, gdb and emacs (Table 1).

Table 1. Software List

Office MS Office 2003 Pro. Sun StarSuite8

CAD CATIA 3D tools for Chemistry CAChe

Graphics Adobe Illustrator Adobe Photoshop Elements ImageJ

Data Analysis MATLAB Mathematica

Word Processing

TeX/LaTeX/pTeX (for Japanese version)

Web Browser MS Internet Explorer Firefox

Mail tool AL-Mail Thunderbird

Windows

Antivirus McAfee Antiscan

Linux Programming gcc/gdb/ddd Fortran90 Emacs

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGUCCS'06, November 5–8, 2006, Edmonton, Alberta, Canada. Copyright 2006 ACM 1-59593-438-3/06/0011...$5.00. .

221

A dual-boot system has, however, had problems with system maintenance. Rebooting to activate another operating system is a time consuming and cumbersome operation for general users. To reduce such time loss, we must install and maintain a commonly used tool suite including editors, E-mail reader, and web browser on each operating system. But, this would increase the system management cost in proportion to the number of operating systems, that is, computer lab staff would have to repeat the boot and shutdown process to apply patches to both Windows and Linux.

To cope with this maintenance problem, we have decided to use coLinux, which provides Linux as a Windows application. Our system consists of 35 servers and about 160 PCs and we have installed Windows with coLinux in all PCs. Now, we will only have to maintain applications on a single operating system (Windows), which will reduce maintenance cost of updating programs and fixing the problems of installed applications. Of course, the availability of two kinds of platform has several good points in the educational view. For example, students can learn file formats commonly used by applications on Windows and Linux, similarity of file structures, the difference in file access control, comparison of command shell and UNIX shell, etc.

In Section 2, the requirements of our system and design concepts are described. In Section 3, technical implementation issues are discussed. We conclude our paper with our result and future works.

2. BASIC DESIGN 2.1 Requirements of two platforms Other requirements for the environment of Windows and Linux system are the following:

Home directory should be shared by Windows and Linux environment. It is often implemented with a network file system.

Software maintenance should be done by a single tool on Windows such as Reference disk image distribution, Revert original disk image by rebooting and Fixed profiles.

2.2 Virtual Machine Technologies To run the two or more operating systems concurrently on one PC, one of them must provide a virtual machine function. We use “HostOS” which runs natively on the PC and “GuestOS” which runs on the virtual machine. Virtual machine technologies are classified into four categories as follows.

2.2.1 Full-virtualizations A “full-virtualizations” emulates whole PC behavior including BIOS and hardware. VMware, Virtual PC, and QEMU are in this category. They are application software on the Host OS and enables unmodified OS to run as the Guest OS. However, VMware and VirtualPC require the GUI environment and QEMU can not provide enough performance now.

2.2.2 Para-virtualizations A “para-virtualizations” is based on the special micro-kernel for executing multiple OS instances. Xen is the most famous

implementation. The performance of the GuestOS is high. However, GuestOS on Xen must be modified. We cannot use Xen for Windows because the Intel Virtualization Technology was not available on our PCs.

2.2.3 Software kernels This method emulates only the kernel of GuestOS, not the whole PC behavior. The coLinux and User-Mode-Linux are in this category. The GuestOS must be modified. GuestOS is a single application. It resembles “full-virtualization”, but its implementation overhead is lower.

2.2.4 API-level compatibilities This is the method based on another emulation layer from the above three technologies which use the modified/unmodified kernel as GuestOS, so the applications on GuestOS are identical on the native OS. On the other hand, “API-level compatibilities” emulate library API only. Cygwin and wine are in this category. Many applications run on this environment, but there are some restrictions against full compatibility of native OS such as process management.

2.3 Choice of VM technology We chose coLinux for the emulated Linux environment for the following two reasons:

First, we wanted to continue to use our Windows management system and schemes. Since coLinux is a single application on Windows, we only have to install the coLinux. We do not need to use any other management systems.

Second, coLinux can run as a Windows Service Application. VMware and VirtualPC need GUI at activation and it would take time before they become available. In contrast, by using Windows Service, coLinux can become ready soon after the Windows startup. This makes users' repeated logon and logoff comfortable.

3. IMPLEMENTATION 3.1 User Interface for coLinux The standard user interface of coLinux is a CUI (Character/Command User Interface). To run GUI applications on Linux, the X Window System is necessary. The X Window System consists of an X server and X client applications. X client applications run on Linux and an “X server” must be run on Windows. ReflectionX, X-Win32, and Astec-X are proprietary “X server” application for Windows, but they are costly.

VNC (Virtual Network Console), widely used in open source community, is a remote desktop environment like a Remote Desktop on Windows. VNC is preferable because its protocol is lighter than X protocol. Moreover, we also decided to use MetaVNC. MetaVNC pursues a remote desktop environment so that users can control applications on different hosts seamlessly. MetaVNC merges windows of multiple remote desktops into a single desktop screen.

Figure 1 is a sample screenshot on our system. In one Windows desktop, windows of Windows application and Linux applications are displayed seamlessly.

222

Figure 1: Sample Screenshot

Figure 2: Virtual network configuration in a PC

3.2 Network interface for coLinux coLinux can handle two types of the virtual network interface. One is “TAP-Win32”, which emulates an Ethernet device. The other is “WinPCAP”, which peeks and pokes the “real” Ethernet device on HostOS. Since we require that users’ home directories can be shared between Windows and Linux environment, the

performance of a network interface is very important. It is already known that “WinPCAP” type has lower performance than “TAP-Win32”, so we chose to use “TAP-Win32” for coLinux’s network interface.

Moreover, there are three methods for connection between the “real” network interface on Windows and the virtual network interface on coLinux.

First, we can connect them using “Internet Connection Sharing (ICS)”. ICS is one of Windows native system and based on NAPT (Network Address and Port Translation) technology. It can be easily used, but we cannot access the Linux system from the outer side of the PC (the left side of Figure 2).

Second, we can connect two or more network interfaces using the “Bridging Connections” function provided by Windows XP. It enables to share the network between Windows and Linux and shows very good performance. However, due to the Windows implementation, if we let PC bridge the “real” network interface and virtual network interface on coLinux, Windows changes the MAC address for the “real” network interface. Therefore, we cannot use the management tools based on PC’s MAC address (the right side of Figure 2).

223

Third, we can connect the two network interfaces using an “EtherBridge” application. “EtherBridge” is usable for Windows2000 or later. It provides the same function as “Bridge Connections” without changing the MAC address.

We chose to use “EtherBridge” for network connection for coLinux. Moreover, we setup another virtual network interface for local connection (Figure 2). Users can uniformly access coLinux on the local PC with “192.168.1.2”.

3.3 Linux OS image for coLinux coLinux can provide two types of interfaces for the Linux OS disk image. One is “one file on Windows”. It is one large file (4GByte in our system) in the Windows file system and it needs no additional management tools for Windows partition. The other is “physical fdisk partition”, which is formatted with Linux native file system (ext3). We have been using DriveShield and Altiris for managing Windows disk image. “DriveShield” can erase all the changes in the specified Windows partition by a reboot. “Altiris” can distribute the model disk image into all PCs’ HDD via network. It can also handle Windows native file system (NTFS).

Therefore, we chose “one file on Windows” for coLinux’s OS disk image. It needs no additional tools for maintaining the coLinux disk image file. Moreover, we have implemented unionfs to minimize the change of disk image under Linux environment [3]. We applied this technique to our coLinux system.

4. RESULTS We described how we built our educational computer system using coLinux, EtherBridge, and MetaVNC to provide a Linux environment on Windows PC.

Our system has advantages with the following points.

Switching time of dual OS environment is almost zero. No need for a boot selector, and no need of lecturing how to

use boot menu. No need for an additional set of software that would be

normally required in a standalone Linux environment. Users can choose his/her screen mode from (1) Windows

native mode without VNCs, (2) Window-Linux mixed environment with MetaVNC, and (3) full-screen Linux environment with (normal) vncviewer.

On the other hand, our system has the following disadvantages.

Slower than native Linux on the PC Not suitable for heavy graphical applications due to VNC

protocol overhead

The single sign-on between coLinux and Windows is a future work.

5. ACKNOWLEDGMENTS The authors thank Hirofumi, U. in NEC System Technologies, Ltd. This research was supported in part by Grant-in-Aid for Scientific Research (No. 17500050), Ministry of Education, Science and Culture, Japan.

6. RESOURCES VMware http://www.vmware.com/ Virtual PC http://www.microsoft.com/japan/windows/virtualpc/ QEMU Emulator http://fabrice.bellard.free.fr/qemu/ Xen http://xen.cl.cam.ac.uk/Research/SRG/netos/xen/ Intel Virtualization Technology http://www.intel.com/technology/computing/vptech/ coLinux: Cooperative Linux http://www.colinux.org/ UML: User-mode Linux Kernel http://user-mode-linux.sourceforge.net/ cygwin http://www.cygwin.com/ Wine http://www.winehp.com/ etherbridge http://www.ntndis.com/utilities/etherbridge.shtml DriveShield http://www.idk.co.jp/products/PCprotecttool/ Altiris (Deployment Solution for Windows http://www.netjapan.co.jp/e/product/control/DS/

7. REFERENCES [1] Hideo, M. (Editor) The Large Scale Educational Computer

Systems, IPSJ MAGAZINE, Vol.45, No.3 (Mar 2004), 225-281 (in Japanese).

[2] Shin-ichi, T., Hirofumi, E., Kenzi, W. and Yoshiaki, W. Diskless Dual Boot Terminal System, IPSJ MAGAZINE, Vol.45, No.3 (Mar 2004), 250-254 (in Japanese).

[3] Hideo, M., Akinori, S., Seigo, Y. and Michio, N. Diskless Linux system with unionfs for an educational computer center, SIGUCCS 2005 Proceedings (Nov 06-09), 207-210.

224