Ability to Hibernate VMs to support DevTest workflos
The new DevTest Azure portal feature has the ability to turn off VMs on a schedule to support dev/testing without breaking the budget. It would be nice if the VMs could be hibernated instead so that developers would not lose their development sessions/window settings etc. when they start off in the morning. But I understand that the ability to hibernate VMs in Azure is not currently a core feature that exists. It would be very nice if that feature could be added. I'm sure there are other use cases where VM hibernation could be very handy too.
This is something that we are reviewing to determine when we can support the functionality.
To CIOs / CFOs / CEOs: Even among IT software developers (probably the most “’powerful’” of PC / VM / OS "'power users'"), I was a religious adherent of the DRY Principle (in all things not just software development) and kept much more, than even my peers, frequently-used apps (dozens) and, in most of each of those apps, frequently-used tabs / windows (dozens) opened, sized, positioned and scrolled. I instinctively save (via keyboard shortcut of course) after every few seconds of pause in making any changes, so I don't bother with using up my precious time shutting down apps properly in case of forced logoff / shut-down due to updates / power outage.
But even just re- opening / sizing and positioning all those frequently-used apps and tabs / windows took me ~45 min, each time there was a forced logoff / shut-down due to required updates / power outage!? Now assuming a probably conservatively estimated cost (incl. co-paid ins. premiums) of $60 / worked* hr. (*not incl. holidays / PTO / etc. and ~48 worked wks / yr.) for an IT worker, if it took them even just 15 min. / worked-day to re- open / size and position even just 1/3 (or probably less since I probably do it quicker via keyboard vs. the mouse most even IT workers still often use) of the same # of frequently-used apps and tabs / windows (or to properly shut down and re-open ~1/2 or less as many), even if it were (like a fabled frog in a slow boil) spread out throughout the day, it would cost ~$330 of LOST PRODUCTIVITY* / IT worker / MONTH!? Does forcing logoff an extra 13 hr. / work day (assuming a probably conservative “8 + 1-hr. lunch” day and 2-hr logoff timeout) + 24 hr. / non-workday (of high RAM but low compute / bandwidth usage) save that much in Azure compute costs??? Even if the alternative were to exempt, from timeout-triggered (not required updates-triggered) forced-logoff, just the IT workers and/or the few who requested and were approved for it???
*That doesn’t even include the costs of delayed productivity gains by the users of IT workers’ (esp. software developer ones) work output, which probably has a far greater “force multiplier” effect than most other types of (at least non-management) workers.
Btw, I agree with the other commenter suspecting MS dragging their feet in fear of less charges due to more efficient use of resources. But in the end, what matters is what you do relative to the competition, and if physical PC OSes and AWS VMs allow it, ...
Robert Turnage commented
Do we have status on when a hibernate feature will be possible?
Sascha Müller commented
Any news regarding this! Would be nice that you do not need to close everything...
Sal Sheikh commented
Can you please add hibernation on VMs? very important feature...
HI what is different between azure and aws RDP which is better
@Azzure IaaS Engineering Team : Any progress on this? It looks like you've been reviewing for a year now...
This should be a core feature for productivity on Azure VMs.
Start times are already slow, resuming from hibernation would be a feasible way to resume work.
Currently we use a 3rd party tool that works through the Azure Portal... Its called "Park My Cloud" it allows you to Schedule a servers hibernation hours e.g. mon-fri 6pm-6am
We just had a huge row with our developers as we wanted to shut down our developer VMs overnight to save costs. The developers went crazy due to having to start all their applications etc each morning.... The final decision.... we leave them all running 24/7, even though they're only used during core times Monday - Friday. What a waste.
Paul M commented
Our organization would greatly benefit this feature. We run many applications which have to be shut down manually then restarted manually when the VM is restarted.
Jason L commented
Please provide Spot Hibernation for machines.
Rajesh Mag commented
Any way to persist and restore to same memory state is fine, like Hibernate/Sleep.
Simon Sebright commented
What is the problem with this? Worried about losing revenue due to more efficient use of your machines? You may find the reverse, that people are more willing to use machines if they feel they can get the most out of them
Windows 10 hibernate and deallocate please. Avoid wasted compute hours overnight. Would make a huge difference to VDI cost on Azure. Work with your partners Citrix on this.
Shital Savekar commented
Do it !!!!
Got to agree with the other comments. Most of our dev team would use the auto-start/stop feature of Azure test labs *if* auto-stop hibernated the vm. AWS allows this why not Azure? This feature has been requested for years.
This is a key feature that impedes movement from physical machines to Azure DevTest. I, and I know most of my colleagues are the same, that we don't really shut down our physical machines at the end of the day. Sometimes is can be 1 - 3 months (Windows has grown stable over the years!). Not having this ability is a real hindrance because I will be forced to shutdown the VM to save on running costs. Therefore in my opinion, it will drive the adoption of DevTest feature many times, if hibernation was implemented and it was quite fast at that.
This feature is absolutely needed!
David Lucke commented
At the end of the day, I and every other developer I work with, simply lock our machines, and go home. When we come in the next morning, we unlock it, and continue development where we left off. There's currently a push to get us off desktops and onto Azure, but that requires buy-in from the developers, and if your replacement solution requires adding a half-hour of pointless faff onto the start and end of every workday, you're just not going to get that. This is a must-have.