I understand that the quota limits can be frustrating. Our free trial model and the boundaries it provides are somewhat different than AWS's model. If you would like to "upgrade" your account (which doesn't initially cost anything) and request a quota increase, support can review your request. The form to request is accessible from the page inside the Console that shows what your quota currently is.
We’re investigating this further, it appears there are circumstances where a small image can create small disks.
Thanks, Sergey, it does look like you have 1GB disks, and I think we've found out a reason why. We're investigating further, thanks for the additional info.
We believe that this is confusing, but not a bug. DISKS are required to be 10GB minimum. However, the archive size of an IMAGE can be smaller. Creating a Disk from an Image that is smaller than 10GB will still result in a disk of at least 10GB.
When you imported your tar file of an image needing 1GB, the Image that was created would end up getting set to create 10GB disks. You can confirm that this is likely true by running 'glcoud compute images describe' on your Image. It likely has a property called diskSizeGb that is likely set to '10'. For example, if you run this command on a recent CentOS 6 image, you'll see that the "archive size" is about 4 billion bytes, but diskSizeGb is '10'.
gcloud compute images describe --project=centos-cloud centos-6-v20161027
Because images have such a setting for how big the disk will be, in your example the instances create from the Instance Template should end up with disks that are 10GB, which is not an error. However specifying --boot-disk-size less than 10GB *is* an error, and that's what the parameter you mention is verifying.
(Issue imported from https://code.google.com/p/google-compute-engine/issues/detail?id=66)
The real problem here is that GCE networking does not currently support GRE.
The 1460 MTU is configured due to additional header space required inside Google's network. It is a difficult thing to change, but something that we're looking at.
Note that unfortunately due to the complex nature of software and network topologies where this sometimes becomes a problem, we likely won't be able to diagnose or debug individual use cases in this forum.
A user on code.google.com notes:
This feature would be nice. You can work around it with ip-tables entries on the target pool instances.
iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080
Could we have the ability to rename static IP addresses?
For example, you may have reserved a static ip address to use as your production ip for your web server, and names it "Production Web IP". Then later on the use of that server may change, and it is no longer used as your production web server, but you need to keep the same IP address (maybe it is registered with some external service as an allowed origin for some service that you will still be using.
In this case you will end up with a Static IP Address called "Production Web IP", that is not what is says it is. Whilst functionally it will work fine, it may become confusing for the purpose of administration in the future.
Therefore it would be useful to be able to rename that static ip address, for example:
gcutil setaddress "Production Web IP" --new_name "SMS Server"
Have you tried editing the instance group to set its size to zero? I believe this will cause the instance group to spin down all the VMs which is what you want to happen.
Noted, Pierre. I'm passing your feedback to our Managed Infrastructure PMs for their review when working on future enhancements. Thx.