Introduction

The Virtual Square

What is Virtual Square?

First of all Virtual Square is the name of a project that includes several software tools and libraries. Its main goal is to create an unified environment that allows virtual machines, systems and networks to communicate and interact.

Virtual Square goals

Although virtual systems refer to a common concept, they are heterogeneous and most of time incompatibile each other. Virtual Square goals can be summarized in the following three items:

1. Communication: in an environment where different kind of virtual machines have to communicate and interoperate an unified virtual communication infrastructure must be provided.
2. Unification: different models of virtual machines have to be integrated and unified in a broaden definition of virtual machine, where each model could be a feature offered by the same virtual machine engine.
3. Extension: a more uniform view of virtuality leads to new applications and extensions of the virtual execution environment.

Design guidelines of Virtual Square

In order to reach predefined goals Virtual Square is designed following these principles:

• Re-use of existing tools

Virtual Square tools enhance the features of existing programs and runs on common operating systems. In this way Virtual Square is not only an academic experiment but results in a well-suited toolkit for real applications.

• Modularity/Compatibility

Every tool have been designed with modular architectures in mind. All tools are composed by interconnecting modules. Once a user designs a virtual architecture for a specific application, the virtual architecture can be put in place by running and interconnecting the modules requested by the application.

• No architectural constraints

Virtual Square tools are highly configurable and adaptable to fit different operational environments and application needs. Via a broaden range of compatibility it is up to the user to decide which tool is best suitable for his/her hardware/software architecture. Architectural constraints imposed by modern operating systems can be viewed just as a lack of design (and not a pure seek of security enforcement). Virtual Square aims to overcome this restrictions in an effective way.

An open laboratory for Virtuality

All the code written within the Virtual Square project is available on public repositories under free software licenses, the most part under GPLv2. Everyone can download Virtual Square tools and test the effectiveness of proposed ideas.

Virtual Square Networking

A common choice adopted by almost all virtual machines is the use of virtual ethernet interfaces. Since an effective virtual networking environment - like the one in Virtual Square - must provide communication between virtual machines, the most natural way to accomplish this task is by supporting an ethernet compliant virtual network able to interconnect virtual machines together. Moreover, a virtual networking support based on a data-link layer abstraction works with every network layer protocol thus allowing easier integration and extension.

Virtual Distributed Ethernet

The Virtual Square networking support have to be an ethernet compliant virtual network able to interconnect virtual machines even if they are running on different hosting computers. This is the reason why the virtual networking support in Virtual Square needs to be distributed.

VDE is one of the tools developed within the Virtual Square project to provide an effective communication platform for virtual machines interoperability.

The main features of VDE are:

• consistent behavior with real ethernet network.
• It enables interconnection between virtual machines, applications and virtual connectivity tools.
• Last but not least, it does not requires administrative privileges to run.

VDE main components

In practice the structure of a VDE network consists of the same architectural tools and devices of a real modern ethernet network. Here is a brief description of VDE components:

• VDE switch

Like a physical ethernet switch, a VDE switch has several virtual ports where virtual machines, applications, virtual interfaces, connectivity tools and - why not? - other VDE switch can be virtually plugged in.

• VDE plug

It is the program used to plug into a VDE switch. Data streams coming from the virtual network to the plug are redirected to standard output and data streams going to the VDE plug as standard input are sent into the VDE network.

• VDE wire

Any tool able to transfer a stream connection can become a VDE wire (e.g. cat, netcat, ssh and others).

• VDE cable

VDE components are interconnected via VDE cables that are made of one VDE wire and two VDE plugs as happen in a physical ethernet network.

• VDE cryptcab

Informally VDE encrypted cable. Although it is possible to use tools like ssh or cryptcat to obtain an encrypted wire to interconnect VDE plugs, these tools work with connection-oriented streams to provide encryption, resulting in nested connection-oriented streams with poor performance and unjustified overhead. The idea behind cryptcab is the adoption of connectionless protocols to provide encrypted cables facility.

VDE connectivity tools

As said before Virtual Square networking environment has to be ready to interconnect heterogeneous virtual machines: to do this several tools have been developed within VDE to allow third party virtual machines to get involved into Virtual Square distributed network.

• vdeqemu

It works as a wrapper for running qemu virtual machines that connects transparently the latter to a specified vde_switch.

• libvdetap

A pre-loadable library that makes possible for virtual machines designed to use Linux kernel tun/tap interface to connect to a specified vde_switch.

• slirpvde

It is a slirp interface to a VDE network. Slirpvde connects all the units (virtual and real machines) to the network of the host where it is running. Such host thus becomes a NAT/masquerading router for the VDE network. This tool includes software developed by Danny Gasparovski.

VDE configuration tools

Like in the most part of professional non-virtual switches, VDE switches provide telnet and web interface to monitor and configure them.

View OS

From the integration of virtual services, new possible applications emerged and limits imposed by existing virtualization tools became clear. It is the case of partial virtual machines. The possibility to have systems where only some parts are virtual appeared as a new and interesting perspective.

Nowadays modern unix-like operating systems provide several tools that give some specific kind of partial virtuality but they have never been used seriously with the partial virtual machine in mind. System calls like the Posix chroot or tools like fakeroot act partially modifying the view that a process has of the underlying operating system. A wider idea of partial virtuality is not compatible with these tools, that were designed to accomplish specific and independent tasks. Like for virtual machines there is the need of a common framework, so new ideas were developed.

A process with a view

Focusing on partial virtual machines and on the idea that they could be build as basic components of operating systems and networking stacks arises the View OS thesis: each process running on an operating system should have its own perspective, its own view. From file systems to networking, devices and inter process communication infrastructure should be redefine-able on every process and by process basis.

Process view vs Global view

Considering the view of two processes running on two different computers the same pathname generally address different files, they have a different perception of the network, different resource ownership and permission. On the other hand two processes running on the same computer have an implicit global view of it: they must share the same network stack and therefore the same network address, the same file system and so on. View OS aims to free the processes from this assumption.

Why View OS?

• Optimization of resources utilization

Although it is possible to give to processes running on the same physical computer a completely different view of the system running processes inside virtual machines, this way of operate is extremely expensive in terms of time and resources. This means that to give a process its own view of the running environment an entire operating system kernel must be loaded into memory, a big chunk of memory must be allocated to emulate virtual machine main memory and so on. This results in a superfluous waste of resources.

• Drawbacks of global view approach

Global filesystem view

In an environment where there is an implicit global view assumption for processes a strict boundary separates system calls that modify processes' view from other less dangerous calls. The former are usually restricted for system administration use while the latter are available also for normal user usage. These restrictions are often due to the global view assumption rather than to a real security issue. In many cases the restrictions appear to be lack in operating system design. For example it is not possible for a user without administrative permissions to mount its own file system images.

Global network view

Global network address within the same physical computer and unique shared network stack provided by the operating system kernel are other aspects of the global view problem. In real world applications the possibility for a process to have its own network stack and network address may be extremely useful. For example it allows processes that act as network servers to be completely independent from the computer where they are running.

View OS aims to overcome this limitations. Each process should be able to define its own view of the world in terms of file system, networking, devices, permissions, users, time and so on. View OS can be seen as a configurable, modular and general process virtual machine.

UMview

What is UMview?

UMview is a View OS implementation as a System Call Virtual machine or to be more precise as a Partial Virtual Machine. A Partial Virtual Machine is a System Call Virtual machine that provides the same set of system calls of the hosting kernel. Having the same interface from process to Partial Virtual Machine, and from Partial Virtual Machine and hosting kernel it is also possible to combine several partial virtual machines together, applying them one on top of the other.