Please see Scott’s comment below that may address your request, or else please edit your feature request to provide further details on what you want to do to interact with instances from Android, or post details via “comment.” Thanks!
Are you looking for this or something else? If something else, please explain a bit more. Thanks!
Thanks, we understand your point of view, and definitely choosing defaults is difficult to do. We will evaluate your suggestion, but please understand that it may be difficult to change, since it could be considered a breaking change to the API (many customers no doubt rely on assumptions of the current behavior at this point).
That would be rather cruel which is why we do provide that functionality:
- in the UI, click the instance in your list of instances to go to the details page
- on the details page, click Edit at the top, scroll down until you see a checked box labeled "Delete boot disk when instance is deleted", uncheck it, then scroll the rest of the way down and click Save (if you have multiple disks attached to the instance, the list of disks will be displayed and you can set the behavior for each via the "When deleting instance: dropdowns).
- you can also use the gcloud compute instances set-disk-auto-delete
We also provide warnings in the UI and gcloud that warn you about disks that will be auto-deleted when you go to delete your instance.
Hello all, I’m happy to announce that you can now change the service account or access scopes on a stopped VM. This feature is available to all users via a beta command, as documented at https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#changeserviceaccountandscopes
Thanks for your patience while we completed deploying this feature.
Note, we are still planning to add the ability to change scopes on a running VM in a future update (it’s at the very top of our list, we know it is a highly requested feature).
Thank you for your continued interest (and patience!). We hope to be able to share more later this month.
We're working on the ability to change the service account and scopes of a stopped VM, so you'll be able to do a stop-change-start instead of delete-recreate.
Good suggestion, thank you!
Thank you for the feedback Jacob. Have you explored our revamped UI recently? You can customize your project "dashboard" with a billing panel that shows current monthly spend for your whole project.
Is that sufficient or would it still be useful if we included daily spend on each product's landing page, e.g., somewhere on GCE's VM Instances landing page?
Thanks for the suggestion!
Thanks for the feedback. We'd love to hear more about your specific workload and/or requirements, e.g., how much local SSD do you need per VM?
First, thanks for the feedback. We'd really appreciate it if you could take the time to elaborate a little more on your specific pain points with the SSH key management. Thanks in advance!
I’m excited to announce a new capability for GCE, scheduled snapshots for persistent disks, is now available in beta. To learn more about how to use this new functionality, please visit the announcement page (https://cloud.google.com/blog/products/compute/introducing-scheduled-snapshots-for-compute-engine-persistent-disk).
This would be a great feature alright. To me, it seems like the best approach would be to provide a general, cross-platform solution, like a GCP cron service, so that it can be used for this use case, as well as use cases for other products (e.g., expire/delete GCS objects/buckets, periodically run a dataflow job, etc.). Thoughts?
We’ve just released a feature to GA which allows you to detach and re-attach boot disks to GCE VMs.
Using this feature, you may now restore a VM from snapshot by:
1. Stopping the instance – (e.g. gcloud compute instances stop INSTANCE_NAME —zone INSTANCE_ZONE)
2. Detaching the boot disk from the VM in question ($ gcloud compute instances detach-disk INSTANCE_NAME —disk DISK_NAME —zone INSTANCE_ZONE)
2. Creating a disk from the snapshot in question
3. Attaching the disk from step 2 to the VM as the boot disk ($ gcloud compute instances attach-disk INSTANCE_NAME —disk NEW_DISK_NAME —boot —zone INSTANCE_ZONE)
After restore, the VM will keep its IP address and other properties (e.g. tags, labels, etc.).
See more info about the feature in the docs:
Down the road, we’re also planning to improve this flow to be “one-click easy.” More updates to come.
Apologies, but I don't quite understand what you are asking for?
We document all that information here:
We are also working on changes to improve the error messages and reduce the need for customers to explicitly request quota increases.
Based on a small number of customer requests, I am moving this from Declined to Under Review so we can accept further votes and feedback on whether some kind of “undelete” would be valuable.
There are a few options for mitigating the risk of accidentally deleting a VM:
- always set the auto-delete flag of the boot PD to 'false' when creating/deleting VMs, that way the boot PD is preserved and you can re-create the VM from that if needed
- create a snapshot of the boot PD before deleting a VM
- stop the VM instead of deleting it
In each case, you'll have what you need to recreate the VM later, and after enough time passes without needing to recreate, you can just cleanup the resources.
Definitely an interesting feature for certain use cases. We'd love to hear from anyone else with use cases suited for this feature, please vote & add comments.
Regarding LVM, though, I wanted to note that you get max PD performance with just the basic PD volume, no striping is necessary. PD performance is capped at the VM level so LVM isn't required to get the best PD performance.
Can you add a little more information about what you are asking for here? What do you mean by "average load"? Is this a request to show additional utilization information in the Developers Console? Feel free to add a screenshot to help us understand.
This is something we are planning to improve, hopefully later in the year.
An Instance Template is for stamping out VMs for Managed Instance Groups, ensuring that the VMs within a MIG are all the same. Semantics for allowing edits to ITs, then, could get pretty ugly resulting in weird restrictions (e.g., only allowed to edit if it is not part of an active MIG) or bad MIG behavior (e.g., a MIG has a mix of VMs because the IT was edited).
Our current thinking is that it is safer and conceptually consistent to simply have the user create a new IT, but I'm interested to hear what the community thinks so I'll leave this one open for more comments for now.
I'm a PM on GCE. I'm not quite clear on the exact behavior you are describing, could you or one of the other voters add a comment with the steps you took to repro the issue, what you saw, and what you expected? Screenshots are always welcome and often very helpful.