A virtual machine (VM) abstract a physical machine. The goal is to run multiple operating systems on a single machine, where each OS believes they’re the only one running.
Basics
The hypervisor (or virtual machine manager) controls virtual machine creation, management, and isolation (which hardware it’s able to use), and operates between the VM kernels and the hardware. There are two kinds of hypervisors. Type 1 is bare metal hypervisor, running directly on the host’s hardware. Type 2 is hosted hypervisor, which simulates a hypervisor and runs in user mode.
Hypervisors can pause the guest OS (basically a context switch), just like processes. VMs are also isolated from each other and the host (any virus infected VM is effectively contained). Hypervisors can set limits on resource uses. Hardware hypervisors are ring -1 (more privileged than the kernel), which allows it to control the guest. For type 2 hypervisors, the host has to create a virtual kernel/user mode.
Any illegal/privileged guest instructions should generate a trap, where the hypervisor explicitly handles the error, simulates the operation for the guest, and resume it (will slow down execution). Note that this doesn’t always work since some ISAs were designed before VMs were invented.
Note that in type 1 hypervisors, the host kernel claims the hypervisor and is the only one able to access it.
In guest user mode, operations can run natively. In kernel mode, the hypervisor has to inspect every instruction before execution (this is what Valgrind does). Special instructions (like old x86 instructions) need to be translated to instructions with the same effect. Guest kernels will use CPU instructions to switch from user to kernel mode. Hypervisor can handle that with trap-and-emulate.
VMs execute bytecode: the equivalent of machine code. These are often more complicated than stock assembly instructions, and often specific to the VM’s intended purpose (like emulation of other ISAs).
The key abstraction is a virtual CPU (VCPU). It functions as the equivalent of the process control block — it stores the state of the CPU when the guest isn’t running.
If there’s less physical CPUs on the physical machine, the host could still present multiple virtual CPUs to the guest. This means there needs to be some scheduling or mapping from the VCPUs to physical CPUs. There are also hypervisor threads.
Guest OS probably runs too unpredictably for real-time tasks. This probably means processes miss deadlines they wouldn’t have had running on an original host.
Virtualised memory management is more complicated too. Guest thinks it controls physical memory and does page table management. Hypervisor maintains nested page table then re-translates for the guest. For overcommitted memory the hypervisor can provide double paging, where it does its own page replacement algorithm.
GPUs: means gaming, ML in virtual machines viable
no point in deploying an entire VM for a single application. containers are lighter weight and reuse the same VM
Docker needs Linux kernel
Sub-pages
- Popular VMs