logo1
GSD Skill Creator
OpenStack Cloud Platform

Documentation > Specialized Systems > OpenStack Cloud Platform

Guide IDSS-5
AudienceSysAdmins, DevOps engineers
PrerequisitesGS-1: Installation, Linux administration experience
Time25 minutes
DifficultyAdvanced

OpenStack Cloud Platform

The OpenStack cloud platform extends the Den's infrastructure from single-host virtualization to a cloud-capable provisioning system. Where the Den's base scripts manage VMs directly on local hypervisors, the OpenStack integration adds API-driven resource management, multi-tenant isolation, and standardized cloud workflows. This guide covers the platform architecture, VM provisioning approach, PXE boot integration, monitoring and alerting, and hardware profile management.

Platform Overview

The Den's OpenStack deployment serves a dual purpose: it provides a production cloud platform for hosting workloads, and it serves as a learning environment for cloud administration. The operational documentation in docs/openstack/operations/ covers the full lifecycle -- from initial deployment through day-to-day operations to incident response and capacity planning.

The operations library includes eight focused guides:

  • Admin Guide -- Core administration tasks: user management, project quotas, flavor definitions, and service configuration.
  • Backup and Recovery -- Snapshot management, volume backups, database exports, and disaster recovery procedures.
  • Capacity Planning -- Resource forecasting based on hardware profiles, workload characterization, and growth projections.
  • Day-2 Operations -- Ongoing operational tasks: log rotation, certificate renewal, service health checks, and routine maintenance windows.
  • Incident Response -- Runbooks for common failures: compute node outages, storage failures, network partitions, and service degradation.
  • Monitoring and Alerting -- Prometheus integration, dashboard configuration, alert rule management, and escalation procedures.
  • Security Hardening -- Network segmentation, API authentication, TLS configuration, and audit logging.
  • Upgrade Procedures -- Rolling upgrades across OpenStack releases with pre-flight checks, staged rollout, and rollback plans.

VM Provisioning

The Den's VM provisioning system is hypervisor-agnostic, supporting KVM, VMware, and VirtualBox through a common abstraction layer. The provisioning scripts accept a VM specification (CPU cores, memory, storage, network) and a target hypervisor, then generate the appropriate configuration and launch the VM.

The provisioning workflow follows these steps:

  • Resource check -- Verify that the requested resources fit within the current resource budget. The budget calculator in infra/local/resource-budget.yaml tracks total capacity, host reservations, and existing allocations. New VMs are rejected if they would exceed available headroom.
  • Template selection -- Choose a kickstart or cloud-init template for the target operating system. Templates define package selections, network configuration, user accounts, and post-installation scripts.
  • Network configuration -- Assign network interfaces using bridge connections detected during hardware discovery. The hardware capabilities profile identifies available network interfaces, bridge support, VLAN capabilities, and DNS configuration.
  • VM creation -- Generate hypervisor-specific configuration (libvirt XML for KVM, VMX for VMware, VBoxManage commands for VirtualBox) and launch the VM.
  • Post-provisioning -- Run post-creation hooks: register with monitoring, configure backup schedules, update the resource budget with the new allocation.

PXE Boot Integration

PXE (Preboot Execution Environment) boot enables network-based OS installation for bare-metal machines. The Den's PXE infrastructure serves three services over the local network:

  • DHCP -- Assigns IP addresses and provides the PXE boot filename to network-booting clients. Configuration includes MAC-based reservations for known machines and a dynamic pool for discovery of unknown hardware.
  • TFTP -- Serves the initial boot loader (typically pxelinux or iPXE) that network clients download and execute. The TFTP server is lightweight -- it only needs to serve the few kilobytes of boot loader code.
  • HTTP -- Serves installation media (kernel, initrd, packages) and kickstart configuration files. HTTP is used instead of TFTP for bulk data transfer because it handles large files reliably and supports resumable downloads.

Kickstart templates define fully automated OS installations. A template specifies the target distribution, package selection, disk partitioning scheme, network configuration, root password (hashed), and post-installation scripts. Templates are parameterized: the same template can deploy Ubuntu or Fedora variants by substituting distribution-specific values. The Den's distribution abstraction layer (detected during hardware discovery) ensures that package names, service management commands, and filesystem paths are correct for the target distribution.

Monitoring and Alerting

The monitoring stack integrates with the Den's Prometheus deployment to provide visibility across all OpenStack services and managed VMs.

Metrics collection covers three layers:

  • Infrastructure metrics -- CPU utilization, memory usage, disk I/O, and network throughput for the physical host and each VM. These metrics feed the resource budget's capacity planning projections.
  • OpenStack service metrics -- API response times, request rates, error counts, and queue depths for Nova (compute), Neutron (networking), Cinder (block storage), and Keystone (identity). Service-level metrics detect degradation before users notice.
  • Application metrics -- Workload-specific metrics exposed by applications running inside VMs (e.g., Minecraft TPS, web server request rates). These are collected via service discovery or static scrape targets.

Alert rules define thresholds and conditions that trigger notifications. Rules are organized by severity (critical, warning, info) and by component (host, VM, service, application). Critical alerts require immediate response (host unreachable, service down, storage full). Warning alerts indicate developing issues (memory pressure, disk growth rate, elevated error rates). Info alerts record events for audit purposes.

Hardware Profiles

The hardware capabilities discovery system generates comprehensive profiles of each machine in the Den. The profile stored in infra/local/hardware-capabilities-local.yaml captures:

  • CPU -- Model, physical and logical core counts, maximum frequency. Used for VM CPU allocation and performance estimation.
  • Memory -- Total, available, and swap capacity in gigabytes. Used for VM memory allocation and overcommit planning.
  • Storage -- Device inventory with names, types (HDD/SSD), sizes, and models. Total storage capacity across all devices. Used for VM disk allocation and IOPS planning.
  • GPU -- PCI slot, model, and VRAM. Used for GPU passthrough configuration and compute workload placement.
  • Network -- Interface inventory with types, states, and speeds. DNS configuration. Capability flags for Ethernet, WiFi, bridging, bonding, and VLANs. Used for VM network configuration and PXE boot setup.
  • Distribution -- OS identification, kernel version, package manager, init system, and security framework (SELinux/AppArmor). Used for distribution-specific script adaptation.

These profiles feed into capacity planning, provisioning decisions, and monitoring threshold configuration. When a new machine is added to the Den, running the hardware discovery scripts automatically generates its profile and updates the resource budget with newly available capacity.

What's Next