Create the VMs and check the seal

Phases 08 and 09: create workstation and the four servers from the Rocky Linux 9 cloud image, then step inside and prove two things: everything works inside the lab, and everything outside is blocked.

Phase 08 · Create the VMs (~20 min)

Create servera in full, then workstation and the other servers with fixed IPs.

LXD UI: start a new instance

Project rhce → Instances → Create instance.

LXD UI: choose the Rocky Linux 9 cloud image

Browse images, then filter and click Select. The first download takes a few minutes; later VMs reuse it.

Filter	Value
Distribution	Rocky Linux
Release	9
Variant	cloud
Type	VM

Optional: freeze the image for reproducible rebuilds

The image server publishes a new Rocky 9 build every few days and keeps only recent ones. To rebuild later from the exact same image, copy it into your local image store once (copied images don't auto-update), then choose rocky9-lab under Local images:

lxc image copy images:rockylinux/9/cloud local: --vm --alias rocky9-lab     # into the current project, rhce
lxc image info rocky9-lab | grep -E 'Fingerprint|serial|description'

LXD UI: name and profile

Main configuration: name servera, instance type VM, profile default.

LXD UI: pin the IP and attach the extra disk

Open the YAML configuration tab and replace the devices: section with this:

devices:
  eth0:
    type: nic
    name: eth0
    network: rhcebr0
    ipv4.address: 172.25.250.10
  disk2:
    type: disk
    pool: default
    source: servera-disk2

LXD UI: create and start

Create and start. The first boot takes 2–3 minutes: cloud-init installs the packages, then the VM reboots once more to switch SELinux on. The UI shows it running the whole time.

LXD UI: create the rest the same way

Name	ipv4.address	disk2 source	Resource limits (left menu)
workstation	172.25.250.9	none: delete the `disk2` lines	CPU `2`, memory `2GiB`
serverb	172.25.250.11	serverb-disk2	from profile
serverc	172.25.250.12	serverc-disk2	from profile
serverd	172.25.250.13	serverd-disk2	from profile

devices:
  eth0:
    type: nic
    name: eth0
    network: rhcebr0
    ipv4.address: 172.25.250.9

Phase 09 · Get inside and check everything (~10 min)

Enter VMs with lxc exec.
Prove the inside works and the outside is blocked.

Host: every VM is running with its address

lxc exec and the UI's Terminal tab are how you will always get in. Neither uses the network, so the firewall doesn't get in the way.

lxc list

Host: step inside servera and check the first boot

lxc exec servera -- bash

cloud-init status --wait          # "status: done"
hostname                          # servera.lab.example.com
id student devops                 # both users exist
lsblk                             # a 5G disk (sdb) with nothing on it
getenforce                        # Enforcing
rpm -q lvm2 firewalld chrony      # all three installed, no "not installed"
exit

VM: the inside works

Enter workstation as student and move around by SSH, as in the classroom.

lxc exec workstation -- su - student

ping -c2 servera.lab.example.com      # works: VM to VM
ssh student@servera                   # password: student. Short names work too
exit
curl -sI https://rockylinux.org | head -1   # works: internet via NAT

VM: the outside is blocked from inside the lab

These should all fail. The ufw rules don't weaken the seal: if one of them succeeds, check that the seal is loaded with sudo systemctl status rhce-isolate.

ping -c2 -W2 <HOST_LAN_IP>          # the host's LAN address: no reply
ping -c2 -W2 <ROUTER_IP>            # your router: no reply
curl -m3 -k https://172.25.250.254:8443   # the host's LXD API: times out

Host: the lab is blocked from the host too

ping -c2 -W2 172.25.250.10            # "Operation not permitted" or no reply
ssh -o ConnectTimeout=3 student@172.25.250.10

From any other machine on your local network, 172.25.250.x doesn't exist at all: your router has no route to it, and the host would drop it anyway.