At the end of the Google Cloud trial period, my VM was stopped by Google. This is understandable, but what comes next doesn't seem so. I have now upgraded to a paid account, but I am still unable to restart the VM. Google cloud support will not help turn the VM back on. They've told me that my only support option is to post my issue here on Stackoverflow. It seems odd that a business like Google would rely on outsourcing it's technical support to the people here.
So here I am. I thank you in advance for reading my issue.
The error message is:
"Starting VM instance "myinstance" failed. Error: Google Compute Engine is not ready for use yet in the project. It may take several minutes if Google Compute Engine has just been enabled, or if this is the first time you use Google Compute Engine in the project."
I have tried multiple times over two days and I still get this same error. The one thing Google did check and verify is that my billing is set up correctly. The dashboard shows that the billing is linked to the project that contains this VM.
Can anyone suggest any troubleshooting steps or solutions?
Thank you.
Related
I have an old Debian Compute Engine instance (created and running since December 2013) and got an email warning about the turndown of Legacy GCE and GKE metadata server endpoints (more details at https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server).
I followed the directions for locating the process and found that the requests were coming from /usr/share/google/google_daemon/manage_addresses.py. The script seems to be the same as what's at https://github.com/gtt116/gce/blob/master/google_daemon/manage_addresses.py (also with what's in that directory).
I don't recall installing this, so I'm imaging it came with the provided Debian image I used in 2013.
Does anyone know what this manage_addresses.py script is, what it does, and what I should do with it now that the legacy metadata server endpoints are turning down? Is it safe to just stop running it? Or is there a new script I should replace it with? Or should I just try to update it myself to use the new endpoint?
I dug around and was able to trace /usr/share/google/google_daemon/manage_addresses.py as being installed by a package called google-compute-daemon. A search for that brought me to https://github.com/GoogleCloudPlatform/compute-image-packages#troubleshooting which explains that google-compute-daemon has been replaced with python-google-compute-engine. That led me to https://cloud.google.com/compute/docs/images/install-guest-environment . I followed the instructions there and manually installed the guest environment.
I noticed during installation that it said it was removing the google-compute-daemon package (and a packaged called google-startup-scripts), so this seems like the right thing. And I'm no longer seeing any requests to the legacy endpoints. So it seems like at some point the old guest environment failed to update.
TLDR; If you have this problem, follow the instructions at https://cloud.google.com/compute/docs/images/install-guest-environment#installing_guest_environment to manually update the guest environment.
So I was using the free Google Compute engine trial. But I didn't realize in time that the trial is about to end, and now there are important files on the compute engine I'd really need to get.
How would I go on about retrieving files from it?
The support told me that the project is still active, just my billing is closed (since the trial ran out)
I tried to use the scp command in gcloud SDK shell, but couldn't really understand how to use it.
The virtual machine is running Windows Server 2016 (desktop).
Any help is highly appreciated.
I'm not very experienced here, but would really need the files nevertheless.
Thanks.
According to the documentation, once the free trial ends, all virtual machines still exist but are stopped (so you won't be able to access them -- and scp doesn't work on Windows anyway).
If you need access to the data, you'll need to upgrade the trial to a paid account, start the virtual machine, copy the data off it, and then stop it; you'll be billed for the time the virtual machine is running (so you may wish to downsize it to save money before you start it).
You only have 30 days from the end of the trial to do this; after this time, the VMs (and their disks) will be deleted (and unrecoverable by anyone).
I have a Bitnami Wordpress Multisite installed on Google Compute Engine. Recently, it was turned off repeatedly with no reason. I have rebooted it via the Bitnami control panel on Jul 2nd and it seemed to work, but now it does not. Here is my compute engine 7-day-report.
One thing to check in this case is the Google Compute Engine VM instance availability setting: it can be either live migrate or terminate, which tells Google Compute Engine what to do with your VM when the underlying host needs to undergo maintenance. Note that there's an automaticRestart setting as well, if you choose the terminate option.
This is a per-VM setting.
If it were set to "terminate", that may explain the issue you saw. Setting it to "live migrate" would mitigate the issue.
You should check your quotas page, you may be running out of something !
Quotas can be found under compute engine menu on the left.
By following steps given in below link I enabled tracing for compute engine.
https://cloud.google.com/cloud-trace/cloud-trace-quickstart
After enabling trace, it seems to automatically get disabled. I have tried many time but same result. Pls help.
At the moment Cloud Trace only traces Google App Engine, so it might not be helpful to you if you are using Google Compute Engine.
Try making sure you have an App Engine app deployed and that you have billing enabled.
We are using Windows Azure platform to host wordpress along with mysql database. Three days ago, all in sudden, we can't save any changes to wordpress. The wordpress shows the changes are successfully made but none of them are taken effective. After googling the problem, it appears that the problem is with mysql permission on Windows Azure. I tried to reach Microsoft, but they direct me to here. I am wondering if anyone experience the same issue and have a solution to this. Thank you.
I found the answer from MSDN forum. The problem with mysql db on azure is that the db is actually hosted at cleardb. azure provision the mysql db as a service but the initial space is 20MB only. It's earsily running out space. I have to go to cleardb dot com to register a payable account and link to azure. Then increase the space. It worked right away.
MSFT currently has very limited support for WindowsAzure. I am not satisfied. But I am glad I can find the answer from tech forum eventually.