Emulation/Virtualisation
Preservation of more complex software systems must consider the operating system and various pieces of hardware.
Virtualisating systems
If hardware or software, on which other software depends, becomes unavailable over time then this underlying hardware or software can be virtualised/emulated. Emulation refers to the ability of a computer program in an electronic device to emulate (or imitate) another program or device. There are various possibilities:
Hardware simulation to reproduce the behaviour of the computer hardware system and peripheral hardware as well as possible - but if the timing of the running of the software may change. There are several system emulators including QEMU
Instruction emulation which involved instructions for the CPU and other hardware being emulated in software such that binary software (including operating systems) will run on systems with different instruction sets without the need for the source code to be recompiled (but little or no guarantee is given to timing and accuracy of the execution of the instructions). For example BOCHS and JPC emulate x86 instructions on a variety of other CPUs.
Virtualisation is a form of emulation where all the hardware is emulated except the CPU. This means a virtualiser can only run on systems with one specific type of CPU. It means one can run a variety of different operating systems and software as long as they are built for the CPU that the virtualiser runs on.
Binary translation is a form of emulation where a binary software application (not operating systems) is translated from one instruction set to another. In this case one ends up with a new piece of software that can run on a different system with a different instruction sets. Software applications are rarely self contained and typically rely on one or more other pieces of software (software libraries etc). In this case not only does the software application need to be translated but also its dependencies may need translating too (if they do not already exist on the new system at the appropriate version). If the operating system of the new target system is different too, then the binary file format that the software instructions are contained in will also need to be translated. For example, Windows software executable binary files have a different format to that of executable binary files on a Linux system.
Virtual Machines (VMs), such as JAVA, take a slightly different approach to running software on a variety of different computer systems. They define a hardware independent instruction set (Bytecode) which is compiled (often dynamically) to the instruction set of the host system. The software that does the compilation is called a Virtual Machine (VM), The VM must be re-written for, or ported to, the host system. On top of these VMs usually sits a unique programming language (unique to that VM) which when compiled is compiled to the VMs bytecode. This bytecode can then be executed with the VM, i.e. it is dynamically compiled to the hardware instruction set of the host system.
The various virtualisers/emulators are themselves software, which themselves need to be preserved. They may be replaced over time by more efficient or more easily preserved equivalents, but until that time they must be preserved.
Complex, distributed interacting systems
Many large scale software systems are separated into smaller specialised, independent, distributed parts, often because the parts are more easily maintained or replaced. Rether than each part running on its own hardware they may be run together on shared hardware. One may imagine that as hardware speed increases such resource sharing may increasingly be used for preserved software.
There are two general ways that this sharing of resources may be achieved, namely virtualising a whole machine or using a lighter container, of which there are several examples.
The various processes often must be orchestrated in order to work together.
Comparison of Virtual Machines vs Containers
Multiple Virtual Machines sharing resources
For Virtual Machines (see also ) the hypervisor make it possible to share a system’s available resources and provide greater IT mobility since the guest VMs are independent of the host hardware. A hypervisor (or virtual machine monitor, VMM, virtualizer) is similar to an emulator; it is computer software, firmware or hardware that creates and runs virtual machines. A computer on which a hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine.
A type 1 hypervisor acts like a lightweight operating system and runs directly on the host’s hardware, while a type 2 hypervisor runs as a software layer on an operating system, like other computer programs. A hypervisor is specific to the hardware and/or host operating system.
Preservation of hypervisor functionality
If the issue is the unavailability of the original computer hardware, a hardware simulator such as QEMU may be used for preservation so that the hypervisor itself may be left unchanged.
There are a number of hypervisor specifications which may be used to re-implement and thereby preserve, the use of VMs.
Containers sharing resources
Containerization allows operating system level or application-level virtualization over multiple network resources so that software applications can run in isolated user spaces in any cloud or non-cloud environment, regardless of type or vendor. Each type of containerization is tied to a specific operating system.
There are many types of containers and container engines, including:
Docker (for more details see Docker and other containers as Other RepInfo
The Container Runtime Interface definition allows multiple, different containers may be used simultaneously.
Preservation of Containerization
if the issue is the unavailability of the original computer hardware, preservation of container engine and all the container software, could be achieved using a hardware simulator such as QEMU, so that the container engine itself may be left unchanged. Otherwise the system would rely on the preservation (including replacement) of the container engine, as would be done for any other piece of software.
Last updated
