VM instance is currently unavailable - not acceptable architecture

[tacoma50]

I stopped a VM instance for 5 minutes. I did not change its HW config. When I tried to start the VM I received this message:  
"Failed to start vm: A g1-small VM instance is currently unavailable in the us-central1-c zone. Alternatively, you can try your request again with a different VM hardware configuration or at a later time."

I tried another HW config and still had the same issue. Eventually a few hours later I was able to start the VM with another HW config than I wanted.

Running applications on VM's that might not restart is not an acceptable strategy.
I could somewhat understand if I was trying to restart a VM with a different HW config that it may not start because that HW is not currently available. But you should ALWAYS be able to restart your VM with its current HW config!

Is behavior normal for GCP CE VM's? Is this something GCP will improve on?
What are some strategies to avoid this situation? Not stopping a VM is not a valid option because sometimes we need to:
 - take snapshot
 - change a boot disc
 - change HW config

[azzi]

Dear tacoma50,

Based on my experience, error above indicated that the resources for g1-small in the zone is currently unavailable due to popular demand among the users in that zone. Easiest way to solve this problem is try to change the machine type to more generally available types such as e2-micro, e2-small, or e2-medium

See https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-resource-availability#resolve_...

Regards,
Izza

[tacoma50]

Hi Izza,
Thank you. That link was helpful, but it does not solve my issue, although it did raise more questions.
The document stated: "This document describes how to resolve resource availability errors that might occur when you try to request new Compute Engine resources or create reservations of Compute Engine resources."

1. In my situation I am not requesting a new resource, I am just restarting an existing VM with no VM config changes.
2. I see the doc mentions "create reservations of Compute Engine resources.". How do I create or setup a resource reservation? May be this is a way I could hold my VM resources while I stop and start it?
3. The doc also states as a solution to try this: "Try requesting the VM in another zone." 
But due to our architecture to minimize costs, our VMs need to stay in the same zone where they were initially created, so this solution does not work for us.
4. Which brings me back to my same dilemma: We need a way to reserve our current VM resources during stop/start. 

[azzi · Accepted solution]

Dear tacoma50,

Every time you stop an instance, the underlying layer (physical host) is released into the zone's resource pool. Therefore, you lose your slot, and your CPU/RAM allocation is reassigned to another user in the zone who would like to use the same machine types as yours.

The error you're getting indicates that all g1-small allocations in that zone are fully utilized, and you did not get a portion at all. Hence, GCP asks you to try it again some other time, perhaps when someone stops their VM. So, the g1-small allocation is available again.

If you want to use a reservation, it is just a different way of keeping your allocation alive even though you don't use it. See https://cloud.google.com/compute/docs/instances/reservations-overview#reservation-billing. You still get charged even during the stopped VM when you use a reservation. Reservations are billed at the same rate as their reserved resources, including the same on-demand prices and 1-minute minimum charges as unreserved, running VMs.

This is how CSPs work in general. They use virtualization to share computer clusters among users so that they can have more specific machine types and pay less than renting the entire cluster. When the user stops the VM, the CPU/RAM allocation will get reassigned to another user. Since the CPU/RAM allocation was reassigned, the original user was not charged, as the CSPs can still generate money from the new user.

Regards,

Izza

P.S. If you want to restart without losing your allocation, you must do it via the terminal using an OS-initiated reboot, such as sudo reboot, etc. Never put your VM into a stopped state. Previously, I recommended using E2 because GCP invested more in this machine type than the others. Which also means the E2 supply could also be much more than the N1/G1

[tacoma50]

Hi Azzi

Thank you for the info on RESERVATIONS. I was unaware of that option and  it it may the solution for my issue! I have read about reservations and have two questions:

1. Just to be 100% clear...  Our project has four N1 VMs. If I set up a reservation in our project for four N1 VMs and then if stop one of the VMs for 24 hours, am I guaranteed that I will be able to start that VM at anytime?

2. I see I am only able to reserve one type of VM such as N1 or E2 within a reservation.
If my project needs four N1 and four E2 VMs, would I able to create two separate  reservations within my project? With one reservation holding four N1 VMs and the othe reservation hold four E2 VMs.

3. I am also wondering if I could use Compute Engine Commitments instead of Reservations to hold my VM resources while I stop and start them?

thank you

[tacoma50]

Using Reservations as recommended by Azzi, I was able to hold our VMs resources during stop of our VMs.