storage plans and licensing

[stidedo]

Hi Alec,

Are there plans to make VAO licensing for storage plans more flexible? Today all virtual servers on a datastore are charged, but there are a lot of use cases where not all servers need to be booted in DR. E.g. customers have one datastore with prod and non-prod systems. Only prod systems need to start up in DR. Splitting into separate datastores is not always desirable and not handy. If we want to onboard new VAO customers we should first start storage vmotions of multiple GB/TB ... to avoid extra licensing costs. Splitting up each customer datastore can cause potential issues in certain circumstances on the VMware side (max 256 NFS datastores per ESXi host) and more LIFS/shared LIFS on Netapp side.

For storage plans, I think, this can be easily fixed to link the licensing part with the "VM step part" of the plan. Each vm with a "register vm" step should have a license attached to it. vm's without the "register vm" will not registered in vcenter DR environment so no other steps/scripts will be executed by VAO (so no extra license is needed). In the long run it would be practical if we could use tags of course.

What do you think?

[Alec King]

Hi Stijn,

As you've found, the VMs for storage failover are automatically grouped per-Datastore, and are all recovered together by design. We didn't go much into the use-case where certain VMs should be skipped from recovery. One reason being that those VMs would become 'orphaned files' if they are not registered after the storage fails over. Any subsequent recovery of unregistered VMs would have to be manual...

Anyway regarding skipping VMs from storage plans, I there are a few ways to accomplish what you request - VM-exclusions, or tag-based groups, etc. I will discuss with the team a few options.

Of course I can't confirm if it's really feasible and even if so, when we might ship such a capability. We have a LOT of plans for Veeam Orchestrator, and not everything can be priority one! However we will discuss it internally.

Thanks for the feedback!