Enable machines to follow the schedule even if they aren't considered "idle"

[anniekaycruk]

Is your feature request related to a problem? Please describe.
The schedule feature only switches off machines considered idle. Currently we are unable to use the "idle" feature as the CPU utilisation needs to be set very high for it to work (see details below) but many of our users primarily use the GPU so the CPU utilisation remains low (around 6%) - this prevents us from being able to set a "safe" CPU utilisation %. What this means is the "schedule" feature never actually ever switches off the machines.

Background:

We configured the VDI (Ubuntu 22.04) auto-stop feature to stop after 15 minutes of idle time (defined as CPU utilization 30%) — but the VDI isn't stopping as expected. aws verified this by reviewing logs, testing different configurations (e.g., 5 minutes with 90%), and sharing these results with AWS support over several weeks. Based on AWS responses
Idle Time Resets:
Logs show the CPU occasionally exceeds 30% before reaching 900 seconds (15 minutes), which resets the idle timer. For example, one entry shows the timer reached ~839 seconds, but then got reset.
Buffer Time:
AWS adds an internal buffer (5 minutes) to idle time. So, a 15-minute idle timeout effectively becomes 20 minutes before action is taken.
CPU Metrics Discrepancy:
The script used to measure CPU (via psutil) operates at the OS level and is more sensitive than the EC2 hypervisor metrics. Hence, even if the EC2 dashboard shows low usage, psutil might show spikes that cross the 30% threshold.
Working Configuration:
You confirmed that 5 minutes idle + 90% CPU threshold worked as expected, validating that the auto-stop logic itself isn’t broken.
Background Processes:
Spikes in CPU may be caused by background OS processes, leading to false resets of the idle timer.

Describe the solution you'd like
Enable an option to enable the schedule even for machines not considered idle.

Describe alternatives you've considered

Additional context

[Murielxun]

Hi, thanks for reaching out.

Could you provide the RES version for the environment so we could look into it? Schedule feature should still be working when VDI never change to STOPPED_IDLE state. I will look into it on the corresponding version.

Thanks.

[anniekaycruk]

Hi,

2025.12.01

That would be great. FYI on the RES UI it says the following under the help page under the "Configure schedule" section : "Note: Virtual Desktop will only be stopped if there is no active DCV client connected for 2 hours and the overall CPU usage is below a certain threshold. Idle time/CPU threshold are configurable by Admins. This measure is meant to prevent Virtual Desktop to be accidentally stopped while running simulations." which is why I raised this request.

See screenshot:

[Murielxun]

Thanks, I will work on reproducing the issue and head back once I get more info.

[Murielxun]

Hi, I tested in 2025.12.01 schedule works as expected. My idle timeout was set to a really large number that the VDI will never be put into STOPPED_IDLE state. I set the custom schedule for the VDI, and the VDI will only be in READY state during the custom schedule time range. Could you test out in your environment and confirm whether that fits the need?

The Note might be too old for the current RES version.

[anniekaycruk]

Thanks a lot.

I tested this myself. If I put the CPU Utilization Threshold to something very low (like 2%) the machines do not stop according to the the schedule. If I put the CPU Utilization Threshold to something higher (like 30%) the VDI stops as expected. So it seems RES is checking the CPU usage of the VDIs against the CPU Utilization Threshold in order to determine whether a VDI can be stopped - could you confirm?

So I think a valid workaround is to set the CPU Utilization Threshold to something higher (like 90%) but keen the idle timeout very long. This way the machine will never be put into stopped idle state, even if the CPU utilisation is low, but they will stop as per the schedule.

Is this what you are suggesting?

[Murielxun]

Hi, feel like there might be misunderstanding towards the schedule feature and the auto-stop feature.

For the auto-stop feature, you can setup the timeout and CPU threshold in Desktop Settings, under Server tab. The VDI will be put into stopped if under the CPU threshold after the timeout. Actually you can manually modify the configuration /opt/idea/.idle_config.json on individual VDI as currently it can only be set globally.

Under the Server tab, there's Enforce Schedule option that you can enable. If it's set to true, the schedule set up for the VDI will be restart when it reaches that time even when the VDI is already stopped due to low CPU utilization. This event is fired by vdc-controller and checks the CPU utilization before stopping the VDI. Also, after the VDI is restarted by the schedule, if the CPU utilization is still lower than threshold, it will be put into stopped again by the auto-stop feature.

You can set the schedule on individual VDI like this following, or under Desktop Settings, under Schedule tab. However, note that, if you set, for example, custom schedule to 9:00am to 5:00pm when it's already passed 5 pm (eg. 5:05 pm), then the VDI won't be stopped till next day's 5pm.

In summary, the schedule event is handled by the vdc-controller and it checks the CPU utilization before stopping (and after VDI is restarted, the auto-stop check resumes so the configuration could stop the VDI regardless of the schedule). Please correct me if I am wrong, but seems you want the VDIs to follow certain schedule. I think you can set the idle timeout and CPU utilization based on the actual usage so that the auto-stop never kicks in and the CPU utilization is always below the threshold, then simply let the VDIs follow the schedule you set for them.

[anniekaycruk]

Hi

I understand the intention of the features but it doesn't match what I see when I use the product unfortunately.

"In summary, the schedule event is handled by the vdc-controller and it does not check the CPU utilization (but after VDI is restarted, the auto-stop check resumes so the configuration could stop the VDI regardless of the schedule). Please correct me if I am wrong, but seems you want the VDIs to follow certain schedule. "

Yes this is what I want. But this "the schedule event is handled by the vdc-controller and it does not check the CPU utilization " is not what I find when I test this in RES, I find that VDIs do not "stop" according to the schedule unless their CPU utilization is less than the CPU Utilization specified in the Server tab.

For example, when the following settings are applied the VDIs stop according to the custom schedule:

But when the following settings are applied the VDIs do not stop according to the custom schedule:

I understand this is not the intention of the feature but it is what i see when I use the product - and matches the "note". Shall i raise a ticket to enterprise support?

[Murielxun]

Hi, thank you for the patience. Thanks for the clarification and I was able to reproduce following that and I looked into the codebase in detail and seems the vdc-controller does not force stop the VDI, it actually does use the CPU utilization threshold instead of skipping it. Sorry for the confusion.

Then yeah, I believe you can set the CPU utilization to a higher threshold, and the timeout to a higher value so it never kicks in as the workaround for now.

I have created internal ticket and this feature request is being tracked internally. Thanks!

[anniekaycruk]

Thanks so much for confirming!