📅 Resource Reservation with OpenStack Blazar

Most OpenStack scheduling is “give me a VM right now.” Blazar answers a different and surprisingly common need: “reserve me four GPU hosts next Tuesday from 9 to 5.” It adds time-based reservations — leases — on top of Nova, which is invaluable for research clouds, batch windows, and any environment where capacity is contended and fairness matters. I rolled it out for a shared HPC-adjacent cloud where teams kept stepping on each other, and it changed the dynamic completely. Here is the practical setup and the failure modes nobody warns you about.

Understand leases and reservation types

A lease is a time-bounded reservation of resources. The two main flavors are host reservation (you get whole compute hosts) and instance reservation (you get capacity for N instances of a flavor). Getting this distinction right up front avoids most confusion.

openstack reservation lease list
openstack reservation host list
openstack reservation lease show <lease-id>

Host reservation pulls compute hosts out of the general pool into a Blazar-managed pool, so those hosts stop accepting normal on-demand instances. That is the whole point, but it surprises operators who then wonder why their free-pool capacity shrank.

Enroll hosts into Blazar

Before anyone can reserve a host, Blazar has to manage it. Enrolling a host moves it under Blazar’s control via a host aggregate.

openstack reservation host create <compute-host>
openstack reservation host list -f value -c id -c hypervisor_hostname

Once enrolled, the host is reservable. Check that your Nova filter_scheduler includes the aggregate filters Blazar relies on — without them, the scheduler ignores Blazar’s reservations entirely and the whole system quietly does nothing.

Pro Tip: Reserving every host into Blazar starves on-demand users. Keep a clearly sized free pool. The fastest way to anger a shared cloud’s users is to discover that 100% of hosts are reservable and nothing is available for ad-hoc work.

Create a lease and launch into it

A lease books the resources for a window; you then launch instances that consume the reservation. The reservation ID is the link between the two.

openstack reservation lease create \
  --reservation resource_type=physical:host,min=2,max=2,hypervisor_properties='[">=", "$vcpus", "32"]' \
  --start-date "2026-06-20 09:00" \
  --end-date "2026-06-20 17:00" \
  gpu-window
openstack reservation lease show gpu-window -f value -c reservations
# At lease start, launch against the reservation:
openstack server create --flavor m1.large --image ubuntu \
  --hint reservation=<reservation-id> --network private job1

The --hint reservation= is the crucial bit. Without it, your instance lands in the general pool and does not consume the lease, so you “have a reservation” that nothing uses. The reservation hint is the number-one thing people forget.

Debug a lease that won’t allocate

When a lease stays PENDING and never becomes ACTIVE, Blazar could not find resources matching the constraints for the window. The lease and the Blazar manager log explain why.

openstack reservation lease show <lease-id> -f value -c status -c events
journalctl -u blazar-manager -n 100 --no-pager | grep -iE 'lease|aggregate|not enough'

The usual causes are over-tight hypervisor_properties (no host has 64 vcpus free), overlapping leases that already claimed the hosts for that window, or a host that left the Blazar aggregate. The events list shows the state transitions with timestamps, which makes it obvious whether the lease ever got close to activating.

Where AI helps with capacity planning

Blazar turns capacity into a calendar, and reasoning about overlapping windows is fiddly arithmetic — perfect fast-junior work for an AI assistant. I export the current leases and host inventory and ask the model to find conflicts, compute free capacity in a given window, or suggest a lease layout that satisfies several teams’ requests without overcommitting. It is good at the combinatorial bookkeeping I find tedious.

The boundaries are firm. I give it sanitized lease lists and host counts, never Keystone credentials, and it never creates or deletes a lease. The model proposes a schedule; I create the leases myself after sanity-checking that I am not starving the on-demand pool. A generated lease that books every host for a week is a denial of service against your own users, so the human approves and executes. The prompt library has capacity-planning prompts, ChatGPT handles the scheduling arithmetic well, and the monitoring alerts dashboard is where I watch free-pool capacity over time.

openstack reservation lease list -f value -c name -c start_date -c end_date \
  -c status   # the schedule snapshot I hand the model

Instance reservation versus host reservation in practice

Host reservation gives a team whole machines, which is right for HPC and isolation but wasteful when a team only needs capacity for a few VMs. Instance reservation books guaranteed room for N instances of a flavor without dedicating entire hosts, so other tenants can still use the leftover capacity on those machines. Choosing the wrong one is the most common Blazar design mistake.

openstack reservation lease create \
  --reservation resource_type=virtual:instance,amount=4,vcpus=4,memory_mb=8192,disk_gb=40,affinity=None \
  --start-date "2026-06-21 08:00" \
  --end-date "2026-06-21 20:00" \
  batch-window
openstack reservation lease show batch-window -f value -c reservations

Instance reservations are far friendlier to overall utilization because Blazar packs them onto shared hosts rather than fencing off whole machines. I default to instance reservation and only use host reservation when a workload genuinely needs full-machine isolation — bare-metal-like performance, licensing tied to sockets, or noisy-neighbor sensitivity. Reserving whole hosts when instance reservation would do is how a cloud ends up looking full while sitting half-idle.

Reservation hits the scheduler, so watch the filters

Blazar enforces reservations through Nova scheduler filters, which means a misconfigured scheduler silently breaks the entire system. If reservations are ignored — instances landing wherever they like regardless of leases — the cause is almost always a missing filter in the Nova configuration rather than anything in Blazar itself.

grep -E 'enabled_filters|AggregateInstanceExtraSpecsFilter' /etc/nova/nova.conf
openstack reservation host list -f value -c hypervisor_hostname

The AggregateInstanceExtraSpecsFilter (and the placement aggregate setup Blazar relies on) must be active for reservations to be honored. When I inherit a cloud where “Blazar does nothing,” this missing filter is the cause more often than any Blazar setting — the leases are perfect, but Nova never consults them. Confirm the scheduler is actually wired to respect reservations before you debug a single lease.

Clean up expired leases

Leases free their resources when they end, but stale or orphaned leases do happen, especially after manager restarts. Periodically reconcile what Blazar thinks it holds against what Nova actually sees.

openstack reservation lease list -f value -c id -c status | grep -i terminated
openstack reservation host list   # confirm hosts returned to the reservable pool

If a host shows as reserved long after its lease ended, restart blazar-manager and verify the host returns to the pool — otherwise that capacity is stranded.

Conclusion

Blazar brings real fairness to contended OpenStack clouds by turning capacity into bookable time windows. Keep host and instance reservations distinct, always launch with the --hint reservation= flag, protect a free pool, and read the lease events when allocation fails. An AI assistant is a capable fast junior for the calendar arithmetic of conflict-checking and capacity planning — feed it sanitized inventory, keep credentials out, and create or delete leases yourself after confirming you are not starving on-demand users. More OpenStack scheduling guides live under the OpenStack category.