General tips for using Google Compute Engine

This page describes tips that you might find helpful if you run into problems using Google Compute Engine.

Viewing different response formats

The 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, use the --format flag which displays the response in different output formats, including json, yaml, and text. For example, to see a list of instances in JSON, use --format json:

gcloud compute instances list --format json

Viewing gcloud compute logs

The 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 the 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 Google 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 in order to provide proxied access from an instance without an external IP address.

Note that idle TCP connections are disconnected after 10 minutes. If your instance initiates or accepts long-lived connections with an external host, you can adjust TCP keep-alive settings to prevent these timeouts from dropping connections. You can configure the keep-alive settings on the Compute Engine instance, your external client, or both, depending on the host that typically initiates the connection. Set the keep-alives to less than 600 seconds to ensure that connections are refreshed before the timeout occurs. The following examples sets the keep-alives to one minute (60 seconds). Note that applications running on Linux systems don't enable keep-alive by default. Thus server or client need to explicitly set the SO_KEEPALIVE socket option when opening TCP connections (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=5
To ensure that the settings survive a reboot, add the settings to your /etc/sysctl.conf file.

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

Windows client

Under the registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\, add the following settings, using the DWORD data type, or edit the values if the settings already exist:

KeepAliveInterval: 1000
KeepAliveTime: 60000
TcpMaxDataRetransmissions: 10

Accessing Google 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

See the gcloud reference documentation for more information.

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 maximum transmission unit (MTU) of 1460 bytes for Linux images and Windows Server images. Operating system images provided by Compute Engine are configured with the appropriate MTU, so no action is required if you're using one of those images. For custom images, set the MTU to 1460 for custom Linux images and Windows Server images to avoid the increased latency and packet overhead caused by fragmentation.

When creating client applications that communicate with Compute Engine instances over UDP sockets, send a maximum payload of 1432 bytes to avoid fragmentation.

Send feedback about...

Compute Engine Documentation