Skip to content
Development
Skill

/nova

OpenStack Nova compute service skill for deploying, configuring, operating, and troubleshooting cloud compute infrastructure. Covers instance lifecycle management (create/stop/start/reboot/resize/migrate/evacuate), compute scheduling with filters and weights, flavor management,

From plugin
gsd-skill-creator
71102 skills61 agents26 commands1 MCP

Claude Code

$ npx -y skills add Tibsfox/gsd-skill-creator --skill nova --agent claude-code

SKILL.md

nova.SKILL.md
name: openstack-nova
description: "OpenStack Nova compute service skill for deploying, configuring, operating, and troubleshooting cloud compute infrastructure. Covers instance lifecycle management (create/stop/start/reboot/resize/migrate/evacuate), compute scheduling with filters and weights, flavor management, live migration procedures, hypervisor management (KVM/QEMU via libvirt), placement service for resource tracking, CPU pinning, NUMA topology, huge pages, cell mapping, VNC/SPICE console access, and capacity planning. Use when deploying compute via Kolla-Ansible, managing instances, debugging scheduler failures, or planning compute capacity."
user-invocable: true
allowed-tools: Read Grep Glob
metadata:
  extensions:
    gsd-skill-creator:
      version: 1
      createdAt: "2026-02-22"
      triggers:
        intents:
          - "nova"
          - "compute"
          - "instance"
          - "server"
          - "flavor"
          - "live migration"
          - "hypervisor"
          - "placement"
          - "scheduler"
        contexts:
          - "deploying openstack compute"
          - "managing instances"
          - "troubleshooting compute"
          - "capacity planning"

OpenStack Nova Compute Service

Nova is the compute scheduler and instance lifecycle manager for OpenStack. It receives instance creation requests, selects an appropriate hypervisor through the scheduler and placement service, coordinates with Glance for images, Neutron for networking, and Cinder for volumes, then manages the full instance lifecycle through libvirt/KVM.

Nova operates in a cell-based architecture. Cell0 holds instances that failed to schedule. Cell1 (and beyond) holds running instances. The placement service tracks resource inventories (vCPUs, RAM, disk) independently from Nova, providing accurate capacity data for scheduling decisions.

Deploy

Kolla-Ansible Configuration

**globals.yml settings:**

# Hypervisor type
nova_compute_virt_type: "kvm"        # Production: hardware KVM
# nova_compute_virt_type: "qemu"     # Nested virt or no VT-x/AMD-V

# Libvirt container
enable_nova_libvirt_container: "yes"

# CPU and RAM allocation ratios
nova_cpu_allocation_ratio: 4.0       # 4:1 vCPU to pCPU (adjust for workload)
nova_ram_allocation_ratio: 1.5       # 1.5:1 vRAM to pRAM
nova_disk_allocation_ratio: 1.0      # 1:1 (do not overcommit disk)

# Console access
nova_console: "novnc"               # Options: novnc, spice
# nova_console: "spice"             # Better performance, less browser support

# Metadata service
enable_nova_metadata: "yes"

# Nova database password
nova_database_password: "{{ vault_nova_database_password }}"
nova_api_database_password: "{{ vault_nova_api_database_password }}"
nova_keystone_password: "{{ vault_nova_keystone_password }}"

**Deployment:**

# Deploy Nova (as part of full deploy or targeted)
kolla-ansible -i inventory deploy --tags nova

# Verify containers
docker ps --filter "name=nova" --format "table {{.Names}}\t{{.Status}}"
# Expected: nova_api, nova_conductor, nova_scheduler, nova_novncproxy,
#           nova_compute, nova_libvirt (all Up)

**Post-deploy verification:**

source /etc/kolla/admin-openrc.sh

# Verify compute service registration
openstack compute service list
# All services should show Status=enabled, State=up

# Verify cell mapping
nova-manage cell_v2 list_cells
# Expected: cell0 and cell1 with transport_url and database

# Verify hypervisor
openstack hypervisor list
# Should show each compute node with vCPUs, Memory, Disk

# Verify placement
openstack resource provider list
# Should match hypervisor list

Configure

Flavor Management

Flavors define instance resource profiles. Create a standard set:

# Standard flavors (name, RAM-MB, disk-GB, vCPUs)
openstack flavor create --ram 512   --disk 1   --vcpus 1 m1.tiny
openstack flavor create --ram 2048  --disk 20  --vcpus 1 m1.small
openstack flavor create --ram 4096  --disk 40  --vcpus 2 m1.medium
openstack flavor create --ram 8192  --disk 80  --vcpus 4 m1.large
openstack flavor create --ram 16384 --disk 160 --vcpus 8 m1.xlarge

# Private flavor (restricted to specific project)
openstack flavor create --ram 32768 --disk 320 --vcpus 16 \
  --private m1.xxlarge
openstack flavor set --project dev-team m1.xxlarge

CPU Pinning and NUMA

# nova.conf [DEFAULT] on compute nodes
vcpu_pin_set = 4-15          # Pin guest vCPUs to physical cores 4-15
                              # Reserve cores 0-3 for host OS

# NUMA topology filter
[filter_scheduler]
enabled_filters = ...,NUMATopologyFilter

**Flavor extra specs for NUMA:**

openstack flavor set m1.large \
  --property hw:cpu_policy=dedicated \
  --property hw:numa_nodes=1

Huge Pages

# On compute host: allocate huge pages
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# Flavor with huge pages
openstack flavor set m1.large \
  --property hw:mem_page_size=large

Live Migration Configuration

# globals.yml
nova_compute_virt_type: "kvm"
enable_nova_libvirt_container: "yes"

# For live migration, all compute nodes need:
# 1. Shared storage (NFS, Ceph) or block migration
# 2. Same CPU model (or cpu_mode=host-model)
# 3. Matching libvirt versions
# nova.conf [libvirt]
live_migration_tunnelled = false     # Use native QEMU migration
live_migration_uri = qemu+tcp://%s/system
cpu_mode = host-model                # Consistent CPU features across hosts

Scheduler Filters and Weights

# nova.conf [filter_scheduler]
enabled_filters = AvailabilityZoneFilter,ComputeFilter,
  ComputeCapabilitiesFilter,ImagePropertiesFilter,
  ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,
  AggregateInstanceExtraSpecsFilter,NUMATopologyFilter

# Weight classes determine host preference after filtering
weight_classes = nova.scheduler.weights.ram.RAMWeigher
ram_weight_multiplier = 1.0          # Prefer h
Read more
@tibsfox
Ships withgsd-skill-creator

An adaptive learning and coprocessor architecture for Claude Code, built as an extension to GSD (open-gsd)

71102 skills61 agents1 MCP
Get the whole plugin

Stars on GitHub

Momentum

stars in total
71
Star history of Tibsfox/gsd-skill-creator on GitHub, a chart by star-history.com

Other skills on gsd-skill-creator.

aminet-index

aminet-index

Manages Aminet INDEX infrastructure: fetch, parse, cache, and incremental update of ~84,000-entry package database. Use when…

aminet-mirror

aminet-mirror

Selective Aminet package mirroring: single-package fetch, integrity verification, mirror state tracking, bulk download, and sync…

More skills from other plugins.

brainstorming
Auto-invoked

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…

@obra@obraInstall Skill
ask-matt

ask-matt

Ask which skill or flow fits your situation. A router over the skills in this repo.

skills10d309k
@mattpocock@mattpocockInstall Skill
accessibility
Auto-invoked

accessibility

Design, implement, and audit accessible UI to WCAG 2.2 Level AA across Web, iOS, and Android — semantic ARIA roles and labels,…

ecc12d293k
@affaan-m@affaan-mInstall Skill
compiler-commit

compiler-commit

Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits…

react1d252k
@facebook@facebookInstall Skill

Questions about nova.

Which coding agents can use nova?
nova installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.