This page describes tips that you might find helpful if you run into problems using Compute Engine.
For help troubleshooting specific issues, see one of the following sections:
- For steps to troubleshoot general issues with instances, such as if your instance doesn't start up, see General troubleshooting.
- For steps to troubleshoot issues with Windows instances, see Troubleshooting Windows instances.
Viewing different response formats
gcloud command-line tool performs most of its actions by making REST
API calls. The pretty-printed results show only the most important information
returned by any specific command. To see the different response formats,
--format flag which displays the response in different output formats,
text. For example, to see a list of instances in
gcloud compute instances list --format json
Viewing gcloud compute logs
gcloud tool creates and stores logs in a log file that you
can query, located at
$HOME/.config/gcloud/logs. To see the latest log file on
a Linux-based operating system, run:
$ less $(find ~/.config/gcloud/logs | sort | tail -n 1)
The log file includes information about all requests and responses made using
gcloud compute tool.
Selecting resource names
When selecting names for your resources, keep in mind that these friendly-names may be visible on support and operational dashboards within Compute Engine. For this reason, it is recommended that resource names that do not expose any sensitive information.
Communicating between your instances and the internet
An instance has direct internet access only if it has an
external IP address.
An instance with an external IP can always initiate connections to the internet.
It can also receive connections, provided that a
firewall rule is configured to allow
access. You can add a custom firewall
rule to the
default VPC network, or add a new network
with custom firewalls. In addition, you can set up a network proxy
within the VPC network environment to provide proxied access from
an instance without an external IP address.
Note that idle connections are tracked for a maximum of 10 minutes, after which their traffic is subject to firewall rules, including the implied deny ingress rule. If your instance initiates or accepts long-lived connections with an external host, you should adjust TCP keep-alive settings on your Compute Engine instances to less than 600 seconds to ensure that connections are refreshed before the timeout occurs. The following examples set the keep-alives to one minute (60 seconds). Note that applications running on Linux systems need to explicitly set the SO_KEEPALIVE socket option on TCP connections to enable TCP keep-alive (see also Linux TCP Keepalive HOWTO).
Compute Engine instance or Linux client
Run the following command:
$ sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5To ensure that the settings survive a reboot, add the settings to your
Mac OSX client
Run the following command:
$ sudo sysctl -w net.inet.tcp.always_keepalive=1 net.inet.tcp.keepidle=60000 net.inet.tcp.keepinit=60000 net.inet.tcp.keepintvl=60000
Under the registry path
add the following settings, using the
data type, or edit the values if the settings already exist:
KeepAliveInterval: 1000 KeepAliveTime: 60000 TcpMaxDataRetransmissions: 10
Accessing Compute Engine as a different SSH user
By default, the
gcloud compute command-line tool uses the
$USER variable to
add users to the
/etc/passwd file for connecting to virtual machine instances
using SSH. You can specify a different user using the
--ssh-key-file PRIVATE_KEY_FILE flag when running the
gcloud compute ssh
command. For example:
gcloud compute ssh example-instance --ssh-key-file my-private-key-file
gcloud reference documentation for
Interacting with the serial console
You can enable interactive access to an instance's serial console so you can connect and troubleshoot instances through the serial console.
To learn more, read Interacting with the Serial Console.
Avoiding packet fragmentation to instances built from custom images
The VPC network has a default maximum transmission unit (MTU)
1460 bytes for Linux images and Windows Server images. However, the
network MTU can be changed. For details, see
Maximum transmission unit (MTU) in the VPC
When creating client applications that communicate with Compute Engine instances over UDP sockets, you can avoid fragmentation if you set the maximum size of the UDP datagram's data to 28 bytes less than the network MTU. For example, if the network's MTU is 1460 bytes, you can send up to 1432 bytes of UDP data per packet without fragmentation. If the network's MTU is 1500 bytes, you can send up to 1472 bytes of UDP data without fragmentation. The 28 bytes are used for an IPv4 packet header (20 bytes) and a UDP datagram header (8 bytes).