Skip to content
BoKSA

Virtualization

Virtualization

Introduction

Virtualization runs multiple virtual machines (VMs) or isolated environments on one physical machine. Each guest thinks it has its own CPU, memory, and devices. For embedded engineers, virtualization appears in development (VM for toolchain), gateways (Linux + RTOS on SoC), and industrial edge (containers on edge servers) — less often inside a 32 KB RAM MCU.

This article covers hypervisors, full vs paravirtualization, and trade-offs relevant when your embedded product interacts with virtualized infrastructure.

Why virtualize?

Benefit Explanation
Consolidation Many servers on fewer machines
Isolation Fault or compromise contained in VM
Legacy support Old OS on new hardware
Development Reproducible test environments
Mixed criticality Safety RTOS + Linux on one chip (SoC partitioning)

Hypervisor types

Type Runs on Examples
Type 1 (bare-metal) Hardware directly VMware ESXi, Xen, Hyper-V
Type 2 (hosted) On host OS VirtualBox, VMware Workstation

Type 1 is datacenter standard; Type 2 is convenient on laptops for course work.

flowchart TB subgraph type1 [Type 1 hypervisor] HW1[Hardware] --> HV1[Hypervisor] HV1 --> VM1[VM A] HV1 --> VM2[VM B] end subgraph type2 [Type 2 hypervisor] HW2[Hardware] --> HOST[Host OS] HOST --> HV2[Hypervisor] HV2 --> VM3[VM] end

Full virtualization vs paravirtualization

Full virtualization Paravirtualization
Guest OS Unmodified Modified to use hypercalls
Hardware CPU extensions (Intel VT-x, AMD-V) trap privileged ops Explicit cooperation
Performance Good with HW assist Often better I/O, lower trap overhead
Portability Run any x86 OS Needs guest awareness

Paravirtualized drivers (e.g. VirtIO in KVM/QEMU) speed network and disk for Linux guests.

Containers vs VMs

VM Container (Docker, etc.)
Isolation Strong — separate kernel Shared kernel, namespaces/cgroups
Startup Slower Fast
Footprint Full OS per VM Image layers
Embedded edge Heavy Common for microservices on gateways

Containers are not full virtualization — they share one kernel. Still useful for deploying OTA-updatable services on Raspberry Pi-class hardware.

Embedded and real-time concerns

Issue Detail
Timing VMs add jitter — poor for hard RT control inside guest
Device passthrough USB/Ethernet assigned to VM — needed for hardware access
AMP / hypervisor on SoC Asymmetric multiprocessing: core 0 = FreeRTOS, core 1 = Linux
TrustZone / MPU Hardware isolation without full VM

For motor control on MCU, you typically do not virtualize — you partition by core or chip instead.

Cloud and CI context

Your firmware CI may run in GitLab runners on VMs. Infrastructure as code provisions test benches. Understanding VMs helps debug "works locally, fails in CI" environment differences.

Relevant topics

Starting points

  1. Install VirtualBox or use WSL2 — note host vs guest networking.
  2. Compare lscpu inside VM vs host — see virtual CPU count.
  3. Run a Docker container on a Pi — contrast image size to full VM.
  4. Research your target SoC — does it mention hypervisor or TrustZone?

Focus points

  • Hard real-time control loops belong on bare-metal or dedicated RTOS cores — not in a busy VM.
  • Paravirtualized I/O matters for throughput testing of networked embedded devices.
  • Snapshots help reproducible demos — not a substitute for hardware-in-the-loop tests.
  • Licensing — some hypervisors and guest OS licenses restrict redistribution in appliances.

Key points

  • Hypervisors multiplex hardware among virtual machines.
  • Full virtualization traps privileged instructions; paravirtualization uses cooperative hypercalls.
  • Containers isolate processes lighter than VMs — common on edge Linux.
  • Embedded control stays off hypervisors; virtualization matters for dev, cloud, and heterogeneous SoCs.