I have a google compute VM instance that will not stop or be killed.
I don't know where it came from and I can't delete it or pause it. I don't have anything running on it nor is has anything scheduled with it.
'gke-cluster-1-default-pool-....`
That is a VM from Google Container Engine. In the left menu, navigate to Container Engine and check if you have any clusters created. If a cluster was created and then removed it is possible that the VM did not get cleaned up properly.
In you dashboard, there should be an Activity tab. You can use this to filter the activity on the account to see if someone created a Google Container Engine cluster.
Related
How would you use an existing Compute Engine VM instance for a Google Cloud Build pipeline?
I know there's been a similar question in the past, however, the suggested answer is not really what I want - creating and then destroying a Compute Engine with every build.
In settings, Cloud Build allows you to enable "service account permissions" for Compute Engine (Compute Instance Admin (v1)), but I've found no information how to use that permission and service for running the build process with one of your predefined VM instances.
Or maybe I misunderstand the answer in the linked thread above and
COMMAND=sudo supervisorctl restart
actually restarts the existing VM supervisorctl? Any help would be appreciated.
You can't run a Cloud Build build on a GCE instance. The most customizable option you would have is to run the build on a private pool. But even in those cases it's always managed, you never have access to the underlying VM.
Another option would be to start a powerful GCE instance with Cloud Build via the GCE API, run your operations there and then stop the GCE instance.
When running vm instance cluster+ nodes even if I am using and running things on the cluster/ dataproc, the vm instance shuts off automatically after about 30 minutes or so. I cannot find this setting and would appreciate any help re: how to disable this to prevent it from shutting off or even how to configure a new cluster in a way that will prevent this from happening.
Thank you
Default Dataproc clusters do not have any kind of automatic shutdown.
If you are using the older Datalab initialization action, you are probably seeing Datalab's own non-Dataproc-aware shutdown functionality, which you can disable one of the ways suggested here: How to keep Google Dataproc master running?
Otherwise, if you're using some kind of template or copy/paste arguments for creating your Dataproc cluster, perhaps you're accidentally setting "scheduled deletion": https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/scheduled-deletion
If neither of those settings explain your situation, you should visit your "activity logs" from the "Cloud Logging" interface, selecting Cloud Dataproc Cluster, and opening up the activity_log type of logs to see an audit log of who was deleting your cluster. Alternatively, if the cluster still existed in Dataproc, but the underlying VM was being shut down, visit the "Compute Engine VM" log category and also look at "activity logs" to see who was stopping your VMs. Sometimes, in a shared project, a project admin might be running some kind of script to automatically shut down VMs to save cost.
This might be a stupid question.
I'm just curious. I'm new to Redis and would like to experiment with it.
However, I would like to turn the instance on and off whenever I am experimenting as I want to save on costs rather than have the instance running all the time.
But I don't see a stop button like other products such as compute.
Is there a reason for this?
Thank you
You won't be able to manage a Cloud Memorystore for Redis instance as a Compute Engine instance as they are different products with different billing requirements and therefore you can't stop a Cloud Memorystore for Redis instance.
If you are only interested in learning more about Redis you can always install Redis on a Compute Engine instance (see the following tutorial for a clear path as to how to accomplish this or this other tutorial as to how to accomplish this task using docker) and afterwards delete the Compute Engine instance in order for charges to stop accruing.
To avoid incurring charges to your Google Cloud account for the resources used in this quickstart:
Go to the Memorystore for Redis page in the Cloud Console.
Memorystore for Redis
Click the instance ID of the instance you want to delete.
Click the Delete button.
In the prompt that appears, enter the instance ID.
Click Delete.
https://cloud.google.com/memorystore/docs/redis/quickstart-console#clean_up
I was trying to install tectonic on a coreos image in Google Compute Engine. It didn't work out well & I made some configuration mistakes so I tried to delete the VM but now it keeps on creating these instances -
Here are the operations log i found in the google cloud compute admin panel -
which suggests that they are in some kind of a target pool which is recreating these instances on deletion.
Can anyone tell how to fix this & permanently delete all the instances.
We have discussed this issue at this thread, and it seems you have been using a managed instance group with autoscaler and load balancer enabled. The autoscaler is setup to recreate the instances as per the configurations.
In order to delete the entire instance group, you have to delete all resources that are using it first, such as the load balancer, backend services, etc.
Background
In our current Google Cloud Project it seems it's common that people create a VM, start it, do some of their stuff and then just leave it there without turning it off or deleting the VM.
I'm trying to write an automated script that pulls the list of VM instances every day and send an E-mail to the VM owners and see if they forgot to turn off their VMs.
Question
So is there an easy way to find out who created a GCE VM instance using Google Cloud API?
You can view the information in Stackdriver -> Logging -> Logs. The log is a JSON file, the actor field is what you are looking for. You can export the logs for analysis.
See https://cloud.google.com/logging/docs/