A hands-on evaluation of Canonical OpenStack (then referred to as MicroStack) and Apache CloudStack as multi-user ICT learning environments on Ubuntu Server.
| Item | Scope |
|---|---|
| Role | Designer, installer, administrator, tester, and technical author |
| Environment | Dell PowerEdge R620 running Ubuntu Server 22.04 LTS |
| Platforms | Canonical OpenStack 2024.1 and Apache CloudStack 4.17 |
| Hypervisor | KVM/QEMU |
| Evaluation | Isolation, RBAC, fault response, networking, usability, and documentation |
| Outcome | OpenStack for introductory cloud labs, CloudStack for advanced administration labs |
This repository turns my 2024 Bachelor of Engineering thesis into an evidence-oriented technical portfolio. It documents what was built, how it was evaluated, what was observed, and where the conclusions are limited.
- Prepared and administered an Ubuntu Server host for two separate cloud evaluations.
- Installed each platform on the same physical baseline, one at a time, resetting the environment between experiments.
- Configured compute, identity, networking, storage, database, and web management components.
- Provisioned test virtual machines and verified platform service health.
- Created separate student accounts, projects, and roles to test resource isolation.
- Simulated service or node failure scenarios and documented recovery behavior.
- Compared both platforms using the same educational and operational criteria.
The platforms were evaluated sequentially, not operated together. This controlled the hardware variable and prevented configuration conflicts between the two experiments.
flowchart TB
U["Learners and administrator"] --> A["Web UI and CLI"]
A --> O["Test A: Canonical OpenStack 2024.1"]
A --> C["Test B: Apache CloudStack 4.17"]
O --> OS["Keystone, Nova, Neutron, Horizon, KVM"]
C --> CS["Management server, MariaDB, NFS, KVM"]
OS --> H["Ubuntu Server 22.04 LTS on Dell PowerEdge R620"]
CS --> H
See architecture and lab environment for the physical specification, deployment lifecycle, and sanitized network design.
| Criterion | Canonical OpenStack 2024.1 | Apache CloudStack 4.17 |
|---|---|---|
| User isolation | Project resources remained separated between two student users | Account and project separation prevented cross-user access |
| Roles | Clear built-in admin, member, and reader roles |
More granular and customizable role definitions |
| Fault response | Stopping Nova blocked VM management, while running VMs continued; management recovered after restart | Multi-node design provided stronger service continuity in the thesis tests |
| Networking | Private/public networks and security rules were accessible, but advanced setup required manual work | Broader support for advanced topologies and network policy |
| Usability | Faster setup and lower entry barrier | More components, planning, and administrator expertise required |
| Best educational fit | Introductory cloud and OpenStack courses | Advanced cloud infrastructure administration |
Detailed evidence, pass criteria, and limitations are in the comparison and test methodology.
| Area | Contents |
|---|---|
| Architecture | Physical lab, logical design, and experiment lifecycle |
| Canonical OpenStack | Components, deployment notes, and observations |
| Apache CloudStack | Components, dependencies, and observations |
| Security | Threat model, access boundaries, and isolation tests |
| Comparison | Criterion-by-criterion results and decision guidance |
| Documentation | Methodology, environment, reproducibility, and thesis context |
This is a documented 2024 lab evaluation, not a production deployment template.
- The thesis used the
openstacksnap from the2024.1/betachannel. The current product name in Canonical documentation is Canonical OpenStack. - The CloudStack experiment targeted version 4.17. Current releases have different dependencies, compatibility matrices, and installation steps.
- IP addresses, passwords, hostnames, and institution-specific configuration are intentionally omitted or replaced with placeholders.
- Commands that change networking, storage, virtualization, or firewall configuration should only be run in an isolated lab after reviewing the official documentation.
Start with reproducibility and version notes before using any installation command in this repository.
The work demonstrates practical experience with:
- Linux server administration and troubleshooting
- KVM-based virtualization and VM lifecycle management
- cloud identity, RBAC, and multi-user resource isolation
- virtual networking, security rules, NFS storage, and MariaDB
- service health validation and failure-recovery testing
- technical evaluation, documentation, and platform selection
English title: Virtualization Technology as an ICT Learning Environment
Bachelor of Engineering (ICT), LAB University of Applied Sciences, 2024. The complete thesis and its original screenshots are available in the Theseus open repository.
Yevhenii Malin
Bachelor of Engineering (ICT), Finland
Repository content is available under the terms in LICENSE. Product names and trademarks belong to their respective owners.