Name: The Foundation of Iron — Week 13 — Bare-Metal Virtualisation
Author: Amine RAITI

RATIO

THE FOUNDATION OF IRON · COURSE MATERIAL · WEEK 13

◆◆◆

BARE-METAL
VIRTUALISATION
Week 13 of 26 · Block 5 — Bare Metal OS
10h theory · 25h practice

◆

◆ WEEKLY LEARNING OBJECTIVES

1. Distinguish type-1 and type-2 hypervisors
2. Install and configure Proxmox VE (or equivalent) on bare metal
3. Create, start, stop and delete virtual machines
4. Manage virtual resources (CPU, RAM, disk) and understand their limits
5. Take a snapshot and restore a VM

◆◆◆

⚠ WARNING — SHELF LIFE OF VERSIONS REFERENCED HERE

This material uses Proxmox VE as the reference hypervisor (open source, widely adopted in 2026). The instructor may substitute any other type-1 hypervisor available in the training environment — the concepts and objectives are identical regardless of the tool chosen.

◆

Amine RAITI · Infrastructure Architect & SRE
Public document · CC BY-NC-SA 4.0 · AI Powered by Amine
Opération Dindon

RATIO

COURSE OUTLINE · 10H

THEORY GUIDING THREAD

◆

13.1 · Type-1 vs type-2 hypervisors2h

— Type 1 (bare metal): installs directly on hardware, full control of physical resources (link with Week 6 — the hardware seen in microcomputing becomes a virtual resource)
— Type 2 (hosted): runs inside a host OS, less performant but easier to install
— Why this course uses type 1: it is the real production model

13.2 · Core virtualisation concepts3h

— Virtual vs physical resources: vCPU, virtual RAM, virtual disk (qcow2, vmdk)
— Overcommitment concept: allocating more virtual resources than available physical ones, associated risks
— Virtual networking: bridges, VLANs on a hypervisor (anticipated link with the networking block in Weeks 17-19)

13.3 · Snapshots and clones3h

— Snapshot: a picture of a VM's state at a point in time (disk + optionally RAM), useful for testing and risky updates
— Clone: full copy of a VM for quickly deploying a new instance
— Snapshot limits: they do not replace an off-hypervisor backup (direct link with the disk images from Week 7)

13.4 · Hypervisor cluster architecture2h

— Conceptual introduction to a cluster (several physical hosts sharing a resource pool)
— Concept of live migration — will be practised in Week 14
— Shared storage as a prerequisite for high availability (anticipated link with Week 14)

RATIO

EXERCISE 1 · HYPERVISOR INSTALLATION AND FIRST VMs · 12H

Equipment: dedicated physical machine (or the server assembled in Week 6), Proxmox VE ISO (current stable version), bootable USB drive, network connection.

(2h) Installing Proxmox VE on bare metal: partitioning, hypervisor network configuration, accessing the web interface.

(2h) Exploring the web interface: node, storage, network, creating a local storage pool.

(4h) Creating a first Linux VM (using the ISO already mastered in Week 8): resource allocation, system installation, booting and verification.

(2h) Creating a second VM with different resources (less RAM, fewer vCPUs), comparing observed performance with the first.

(2h) Taking a snapshot of the first VM, deliberately modifying the system (deleting an important file), restoring from the snapshot, verifying.

SOLUTION — EXERCISE 1

Post-installation hypervisor check: the web interface should be accessible from a client machine via the IP address configured during installation, on the default port. The node should appear as operational in the dashboard.

Snapshot restore verification: the deleted file should be present again after restoring — this is the concrete demonstration that the snapshot captured the state prior to the deletion. Stress the difference from an external backup: if the hypervisor itself fails, the snapshot becomes inaccessible.

RATIO

EXERCISE 2 · RESOURCE MANAGEMENT AND VIRTUAL NETWORKING · 13H

Equipment: hypervisor configured in Exercise 1, the two created VMs.

(3h) Hot-adding resources to a VM (adding RAM and vCPUs without a restart if supported by the hypervisor), observing the effect inside the guest OS.

(3h) Configuring virtual networking: creating a dedicated network bridge, connecting both VMs to this bridge, testing communication between the VMs (ping, file transfer).

(4h) Controlled overcommitment exercise: configure both VMs with a combined RAM slightly exceeding the available physical RAM, observe the hypervisor's and VMs' behaviour under load (simple stress test tool).

(3h) Cloning a VM, starting the clone, verifying that both instances run independently.

SOLUTION — EXERCISE 2

Expected overcommitment result: with light overcommitment (10-20% beyond physical RAM), the hypervisor uses memory ballooning or swap — VMs keep running but with measurable performance degradation. With heavy overcommitment, the risk of VM crashes increases sharply.

Clone verification: both instances must have different identifiers (IP if DHCP, hostname if reconfigured) — an unreconfigured clone can cause network conflicts, an important point to highlight.

◆ SUMMARY SHEET — WEEK 13 SELF-ASSESSMENT

1. I can distinguish a type-1 from a type-2 hypervisor.

2. I can install Proxmox VE (or equivalent) on bare metal.

3. I can create and manage a VM (start, stop, delete).

4. I understand the concept of overcommitment and its risks.

5. I can take and restore a snapshot.

6. I understand why a snapshot does not replace an external backup.

7. I can configure a network bridge and make two VMs communicate.

8. I can clone a VM.