Max Pool Limit Size

Wow! That sounds like a cool, but (potentially) complicated idea.

If I'm understanding correctly, you'd want some kind of logic like the screenshot below where you can say, “Once my #1 SKU gets to ## threshold, start scaling the #2 SKU on the next Autoscale task. After the #2 SKU gets to # threshold, start scaling the #3 SKU, etc.”

Putting-on my “devil's advocate” hat for a minute. . . 

It would likely involve a redesign of our Autoscaling logic to accomplish this, but could potentially run into a few issues on your (the MSP) or the customer's end:

• License costs (paying for more licenses than you need)
• Not having sufficient hosts while transitioning between SKUs
• Logic behind Nerdio Azure Capacity Extender would need to be adjusted each time you make the SKU jump
• If the wrong SKU is selected and users are logged-in, you'd need to wait for a new host to be provisioned potentially causing some downtime

Ignoring those potential issues, what if there was an AI suggestion of this feature request instead of an automation? (i.e. “I noticed you're running 12-E4as hosts, but 6-E8as host or 3-E16as hosts would be more cost effective. Would you like to schedule those changes for after-hours?”)

Do you think that would be an acceptable alternative or is the automation still preferred?

You are spot on with the first assumption.
I love playing devil's advocate and appreciate the feedback!

I don't think I get you with the license costs though.
The transition would happen at scale down to ensure there would be enough hosts. (if programed that way)
You are right with the capacity extender, what if we had wildcard options in the extender where it only changed either the family or versions but kept the core count the same?
This for sure would be an advanced setting. Maybe even one that is locked behind a support request. Like gaining access to a private preview.

Anyways, I don't take credit for this idea. I was reviewing a competitive product, and they have about 6 features that Nerdio doesn't (yet) have. Notice the 6 new product features I just put in. I wanted to see how many other people might find these features useful and see, if they would be easy enough to implement, when they could be added. Plus, you get the added bonus of not having a competitive product have features NMM doesn't have.

Thanks, Jason.
I'm liking these ideas (trying to catch-up to all of them 😄)

I definitely relate to where your mind is at.
If we can get these implemented, it can make Nerdio that much more of a “no-brainer” decision 😎

For the licensing costs, I'm thinking that if you have software where you pay by the host in advanced and go from 12 hosts down to 6, you'll still be paying for those extra licenses until the term is-up on the licensing and then you can drop-down to a lower license count. (similar to the NCE licensing changes)

Hmm. Transitioning the host pool at scale-in could work.
It might need to be a maintenance window so it could have enough time to do the resizing, but what you're describing sounds like a great method.

Adding a checkbox for the “Utilize Host Pool Family Logic” (not an official name, just thinking out loud) to the Capacity Extender may be a good option. That way, if you know, you can use it but aren't required to use it.

Keep the ideas coming!

That's a great call out on the per host licensing cost piece. It could impact RMM, MDR, print server, etc., licenses.

In some environments those costs would easily exceed the host cost savings.

Speaking of RMM tools, scaling down from 12 to 6 would likely also need some automation to inform monitoring tools that extended unavailability of those 6 now deprecated hosts is expected.

One other area that we learned when increasing the number of users per VDI host is hitting unknown limitations. When doubling the number of users per host, testing it before putting it in production will be critical.

As an example, our users access an application that pulls data via ssh from a Linux server, once we exceeded 80 users per host we began to see new errors. While investigating, we learned that by default Red Hat limits the amount of ssh connections per client to ten. The connections open/close quickly enough that we never hit that limit with 60 users per RDS host, but we started hitting that limit of ten connections per VDI host and seeing errors once we exceeded 80 users.

With the variety between different environments for this tool to function in an automated fashion it would need a significant amount of customization. At first blush, we'd likely need config fields to:

• set maximum number of users per host
• set minimum available memory per user
• input per host licensing cost of third party tooling
• define maintenance windows for the transition to occur

and the automation would have to account for all of those before making a scaling change.

This tool would be very helpful in an advisory role, but with nuance in each environment putting enough controls in to "trust" it to automatically make a change would be tough.

Yikes!
When you put real-world values into the concept, it instantly becomes more complex.
Especially if you have some apps/services that have connection limits.

The Max/Mins should be easy enough, but the licensing cost thing might be a bit difficult to do.
Possibly, we could do something with the PSA integration and pull licensing costs from your PSA and do some calculations for the host and then have some Notification/AI component setup to bring-up cost concerns . . . 🤔

We'll have to see what our Product Team can do with this idea.