2: Userspace-based virtualization (the easy way)

First, consider the "normal" case of a real hardware box running your operating system and your applications. Look at this graphic:

virtualisation-none-60.png

At the bottom there's the hardware. Normally a program cannot access the hardware directly - this is done by the operating system - more specifically by a part of the operating system laying "immediately" on top of the hardware to control it: the kernel. A kernel is not enough to be a usable operating system though, so nearly all OSes have processes. A process is a running program which requests CPU and I/O from the operating system. Such a process can be a server as well as an application program like Microsoft Word. The following graphic is illustrating a Windows XP system running many processes like Yahoo Instant Messenger, Outlook and much more:


virtualisation-none-example-60.png



The first virtualization technique for the classical PC (running Windows or Linux) was a process simulating another "real" PC. You started the program (which became a process) and you had another PC "running" - it's running inside the process. If you stop that program/process, the virtual PC stops:

virtualization-software-60.png


The "big" yellow processes are the "PC emulators", the kernels/operating systems running inside these processes do not know that they are not running on a real computer.

As a real-world example, take Sun VirtualBox running on a Mac OS X computer:

virtualization-software-example-60.png

You see two running "VirtualboxVM" processes (which represent the virtual computers), one of them is running Linux inside, the other is running Windows.
To achieve certain things that a normal software program cannot achieve, most of these virtualization programs come along with special drivers which have to be installed on the host computer system: Direct access to hardware devices if a virtual machine requests it, faster memory access and other things.

The system running inside a virtual machine is named a guest system.
The system which runs the virtual machine is named a host system.


In our example above, the virtual Linux is running processes like ls or bash - or the sshd needed to logon via SSH. The Windows guest is running notepad, word and a task manager (In reality, many more processes are running).

This is a screenshot showing this environment (click to enlarge):

virtualboxexample.png


You see the Mac Safari running just in parallel to the Windows XP virtual machine and the Linux one.

This "userspace-based" virtualization technology is widespread in desktop use, as there are no special operating systems needed (neither for the host nor for the guests) and they're easily installable.

Virtualization programs following this paradigma are - among others:

  • VMWare Player
  • VMWare Workstation (*)
  • Sun xVM VirtualBox (*)
  • QEMU, DOSBOX
  • Parallels Workstation

(*) These products are heading towards a hybrid solution like KVM, VirtualBox can use the hardware virtualization feature of the CPU for example and do not run anymore without special kernel modules. However - the process nature of the virtual pc environments stays intact. They prevent also from being swapped out.

Screen output and mouse/keyboard interaction is often done via special drivers which have to be installed on the guest system. Without these drivers, the machines are working normally but interaction with the host system is often limited and performance losses can be felt.

The virtual machine programs emulate also a predefined set of hardware - the guest operating systems won't see the real hardware (which is controlled by the host operating system - Mac OS X in the example above). That's convenient: You may deploy the same guest operating image on many virtual machines - as each one has the same "hardware".

Take the "virtual disk drives" as an example: Your virtualized guest operating system will see an IDE disk (or a SCSI one, depending on your virtual configuration) which in fact can be just an image file on the host's file system. Copy this file to a new one and give this image to a newly created virtual machine as virtual disk, start it and - tadaa - you have a second running virtual machine having the same configuration.

Through the use of special VM drivers for the host system (white boxes in the graphs above) you can even map a real hardware to a virtual machine - which will have it in exclusive access then (even the host will not be able to use it). It is perfectly possible to map a Fiberchannel card to a virtual machine so the real fiberchannel drivers of the guest operating system take over control of this card. This is somewhat non-typical for this kind of virtualization but it might be useful to run some kind of Windows-only-hardware under Linux. Just map it exclusively to the virtual guest Windows system.

This approch has some drawbacks however: As the emulated/virtual guests are normal processes, the host operating system has complete control of them: If it wants it can swap them out - which is normally not what you want.
All the memory which is "occupied" by the guest (virtual) system is requested as normal process memory from the virtualization process - if the virtual machine is configured to use 512 megabyte you'll end up in a process eating 540 or 560 megabytes (the emulation/virtualization process needs also memory for itself).

Additionally, the emulation of the virtual hardware means that the virtualization process has to "generate" interrupts, clocks and much more resulting in some overhead - when the inside guest operating system consumes 100%CPU the virtualization process will consume more (on a multiprocessor system, otherwise the virtual machine just gets slower).




  1. Why virtualization?
  2. Userspace-based virtualization (the easy way)
  3. Xen: Hypervisor-based virtualization
  4. ESX: Hypervisor-based virtualization
  5. Solaris Zones: A sharing approach
  6. Hybrid methods: KVM



0 TrackBacks

Listed below are links to blogs that reference this entry: 2: Userspace-based virtualization (the easy way).

TrackBack URL for this entry: http://southbrain.com/mt/mt-tb.cgi/96

December 2015

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

About

This blog is owned by:

Pascal Gienger
J├Ągerstrasse 77
8406 Winterthur
Switzerland


Google+: Profile
YouTube Channel: pascalgienger