Heropa measures the resources you use in two separate ways, and they behave differently. Understanding that difference is most of what you need to keep consumption predictable.
This article explains how each is measured, where to see your current position, and which settings actually move the numbers.
Where to see what you are using
Controlling storage consumption
How consumption is measured
| What it measures | When it accrues | |
|---|---|---|
| VLUs | The compute size of the VMs in an environment | Only while a VM is running |
| Storage | The disk taken up by VMs and locally held VM images | Whenever a VM or image exists, running or not |
It's important to understand that shutting a VM down stops VLU consumption immediately, but the environment's disks still exist and still accrue storage. Stopping is not the same as destroying.
Usage appears as VLU hours (VLUs multiplied by the hours they ran) and Storage GB-months (storage provisioned multiplied by how long it was provisioned, prorated hourly across the month).
If you use a BYO cloud account: one VM hour is equivalent to one VLU. Anywhere this article or the platform shows VLUs or VLU hours, read them as VM hours. Everything else below applies unchanged.
VM images provided by Heropa are not counted against your storage allocation. Only images held locally in your own library are.
Where to see what you are using
Dashboard
The Dashboard is the fastest read on your current month. The limits shown reflect your subscription plan.
- Concurrent VLUs — the total VLUs of all VMs running at the same time.
- Monthly VLUs — used against included, for the current calendar month.
- Storage GB — used against included, in GB-months.
- Current GB — storage taken up right now by all existing VMs and local VM images.
- Projected GB — an estimate of where storage will land by the end of the period. This is the number to watch if you want warning before you reach your allocation rather than after.
Usage Report
Under Reports, the Usage Report breaks consumption down in either VLU hours or Storage GB for a period you choose. Group by Environment, User (Owner), Course, Company, Event or Region, and drill into a single environment when grouped by Environment. Any report can be exported to CSV.
This is where you find out which environments, courses or people are driving the numbers.
Per-environment detail
On an environment:
- Usage tab — the start and stop activity of its VMs.
- User sessions tab — activity of individual users in that environment.
- The Environments List shows each environment's total VLU and storage usage.
The Courses, Events and Companies reports also carry usage columns, so you can attribute consumption to a specific course, event or customer.
Controlling VLU consumption
Because VLUs only accrue while VMs run, every lever here is about running time.
Auto-suspend
Auto-suspend shuts VMs down after a period of inactivity. An idle session is triggered after 15 minutes with no user activity in the browser tab; auto-suspend then shuts the VMs down after the interval set in the policy. An auto-suspend of 1 hour means the VMs stop exactly one hour after the idle session was detected.
This is the single highest-value setting for most customers, because it catches the common case: a student who closes their laptop without stopping their lab.
Duration and Destroy after
A policy's Duration sets how long a user has access, counted from first launch. Destroy after sets when the environment is destroyed — which is what ends storage consumption as well.
Active Time Limit
An Active Time Limit caps the total hours a student can access their environment, cumulative across sessions. It can be set above 24 hours, and once it reaches zero the student loses access until more time is added. You can adjust the remaining time on an individual environment or event seat.
Events caveat: if an event starts VMs automatically (Start VMs at start of class hours), those VMs do not consume active time when the participant never enters the workspace - but they are running, so they do consume VLUs. If you are relying on Active Time Limits to control consumption in an event, turn off the scheduled starting of VMs so environments only run when students actually start them.
Weekly schedules
For environments that need to persist, a weekly schedule sets the days, times and timezone in which VMs are available. Note that turning auto-suspend off on an environment requires you to complete a weekly schedule, so a long-lived environment is never left with no stopping rule at all.
Working around the 12-hour ceiling
The longest a policy can keep a VM running is 12 hours. If a VM genuinely needs to run continuously, use the Disable auto-suspend action on that individual VM rather than widening the policy for everything that uses it.
Share expensive resources instead of duplicating them
In an event, the Shared Environments type lets participants reach a resource provisioned once in the host environment - a licence server or a database server, for example. For high-VLU supporting infrastructure this replaces one server per participant with one server per event.
Where a resource needs to outlive the event, the Existing Environments type points multiple events at one long-running environment.
Controlling storage consumption
Storage accrues for as long as things exist, so the levers are about what you keep.
- Destroy environments you have finished with. Stopping a VM ends its VLU consumption but not its storage. Deleting an environment permanently removes its VMs and their data and cannot be undone, so confirm before you do it — but environments left stopped indefinitely are the most common source of quiet storage growth.
- Use Destroy after in your policies so cleanup happens by default rather than by memory.
- Watch Projected GB, not just Current GB, so you see an overrun coming.
- Keep your local VM image library tidy. Images you hold locally count toward storage whether or not anything uses them. Heropa-provided images do not.
Unallocated pools
An unallocated pool pre-provisions environments so students get instant access instead of waiting for a build. When you set a pool size, Heropa creates that many environments in advance — all VMs, networking (including public IPs) and storage — starts them so first-boot configuration completes, then shuts them down when the idle shutdown policy triggers. The pool tops itself back up as environments are issued.
Pre-provisioned environments are shut down, so they are not consuming VLUs. They are still consuming:
- On Heropa-managed accounts — storage from your subscription.
- On BYO cloud accounts — service quota in your cloud account, such as vCPUs, IP addresses and storage. Large pools can push you into quota limits.
Start with a small pool and raise it based on actual demand, rather than sizing for the busiest day you can imagine.
BYO cloud accounts
Everything above applies, with two additions.
One VM hour equals one VLU. Usage figures labelled VLU hours are VM hours for your account.
Watch for orphaned environments. An orphaned environment is one deleted in Heropa where the deletion in the cloud provider failed. It no longer appears in your normal environment list, but it still exists in your cloud account and still costs you money. This is the one consumption problem that will not show up in the usage figures you normally watch.
Heropa checks for orphans every 12 hours and retries deletion up to three times over about three hours. If all attempts fail, the environment is marked delete failed.
To stay on top of them:
- Turn on the notification. Go to Administration / Email templates, select the Orphan Environments template, open the Recipients tab and move the appropriate groups into Notified groups. The email goes out once every 24 hours listing unresolved orphans.
- Review the list. Administration > Orphans shows the current orphaned environments for your company.
- Act on them. From the row or bulk actions you can start or stop the environment, retry the deletion, or mark it as manually deleted once you have removed it in your cloud console.
- Find out why. Open the environment and check the Logs tab for the failed destroy attempts and their error messages.
A practical routine
Most of the benefit comes from a short, regular check rather than a deep audit.
Weekly
- Scan the Dashboard: are Monthly VLUs and Projected GB tracking where you expect for this point in the month?
- On BYO accounts, clear any orphaned environments.
Monthly
- Run the Usage Report grouped by Environment and by Course, and look at the top few entries. Consumption is almost always concentrated.
- Check for long-lived environments that are stopped but not destroyed.
- Review unallocated pool sizes against the enrolment they actually served.
When setting up anything new
- Confirm the policy has an auto-suspend interval you are comfortable with.
- Set Destroy after, so cleanup is automatic.
- Consider whether an Active Time Limit fits the delivery format.
- For events with expensive supporting infrastructure, check whether a shared environment would do.
One thing to know about policy changes: updating a policy - its duration, auto-suspend or destruction rules - flows through to associated courses and environments that have not yet been provisioned. Environments already launched under that policy are not affected. Fixing a policy does not fix what is already running; those need handling individually.
Related articles
- Using policies
- Setting an Active Time Limit for courses, standalone environments, and events
- Using the Dashboard
- Using reports
- Managing environments
- Deleting or Destroying an environment
- Unallocated pool: Pre-provision environments to be used in a course
- Understanding event types
- Orphaned environment reports
- Managing a Bring Your Own (BYO) Azure Cloud Account
- Heropa Glossary
Comments
0 comments
Article is closed for comments.