Virtual Machines (VMs)
1. The Architecture
A VM relies on a Hypervisor (Virtual Machine Monitor). This is the software layer that sits between the physical hardware and the virtualized operating systems.
2. Real-World Examples
A. System Virtual Machines
Emulates a full functioning OS. Used to run software designed for a different hardware platform.
- Oracle VirtualBox: Running Linux on a Windows PC to test web server configurations.
- VMware / Parallels: Running Windows on a Mac to use specific development tools.
- Cloud Servers (AWS/Azure): Your "server" is actually a VM running on a massive physical rig in a data center.
B. Process Virtual Machines
Instead of an entire OS, it emulates an abstract environment to run a single program (Write Once, Run Anywhere).
- Java Virtual Machine (JVM): Java code is compiled into Bytecode. The JVM interprets this bytecode for whatever hardware it's sitting on.
- Flash Player (Legacy): Used to provide a consistent environment for web games across different browsers.
3. Intermediate Code (Bytecode)
This is a key A2 concept. When you use a VM like the JVM, the source code is compiled into Intermediate Code. This isn't machine code yet, but it’s halfway there. The VM then translates this on-the-fly into the specific machine code of the host CPU.
4. Benefits vs. Limitations
- Benefit: Isolation. If a virus infects the Guest OS, it cannot escape to the Host machine.
- Benefit: Hardware independence. You don't need to rewrite your software for every different CPU type.
- Limitation: Performance Overhead. Emulating hardware takes CPU power, making VMs slower than running "bare metal."
In Paper 3, common answers include: testing software in different environments without buying multiple PCs, saving money by "server consolidation" (running many virtual servers on one physical box), and providing a secure sandbox for dangerous code.