Google Compute Engine lets you create and run virtual machines on Google infrastructure. You can create virtual machines running different operating systems, including multiple flavors of Linux (Debian, Ubuntu, Suse, Red Hat, CoreOS) and Windows Server!

But once you've created the virtual machine, you'll probably want to attach large persistent disks to store data.

Follow along this lab to learn how to create persistent disks and attaching it to a virtual machine.

What you'll learn

What you'll need

How will you use this tutorial?

Read it through only Read it and complete the exercises

How would rate your experience with Google Cloud Platform?

Novice Intermediate Proficient

Codelab-at-a-conference setup

If you see a "request account button" at the top of the main Codelabs window, click it to obtain a temporary account. Otherwise ask one of the staff for a coupon with username/password.

These temporary accounts have existing projects that are set up with billing so that there are no costs associated for you with running this codelab.

Note that all these accounts will be disabled soon after the codelab is over.

Use these credentials to log into the machine or to open a new Google Cloud Console window Accept the new account Terms of Service and any updates to Terms of Service.

Here's what you should see once logged in:

When presented with this console landing page, please select the only project available. Alternatively, from the console home page, click on "Select a Project" :

Navigate to the the Google Cloud Console from another browser tab/window, to Use the login credential given to you by the lab proctor.


Once the operations completes, you will do most of the work from Google Cloud Shell, a command line environment running in the Cloud.

This Debian-based virtual machine is loaded with all the development tools you'll need. It offers a persistent 5GB home directory, and runs on the Google Cloud, greatly enhancing network performance and authentication. This means that all you will need for this codelab is a browser (yes, it works on a Chromebook).

To activate Google Cloud Shell, from the developer console simply click the button on the top right-hand side (it should only take a few moments to provision and connect to the environment):


Click the "Start Cloud Shell" button:

Screen Shot 2017-06-14 at 10.13.43 PM.png

Once connected to the cloud shell, you should see that you are already authenticated and that the project is already set to your PROJECT_ID :

gcloud auth list

Command output

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)
gcloud config list project

Command output

project = <PROJECT_ID>

Cloud Shell also sets some environment variables by default which may be useful as you run future commands.


Command output


If for some reason the project is not set, simply issue the following command :

gcloud config set project <PROJECT_ID>

Looking for your PROJECT_ID? Check out what ID you used in the setup steps or look it up in the console dashboard:


IMPORTANT: Finally, set the default zone and project configuration:

gcloud config set compute/zone us-central1-f

You can choose a variety of different zones. Learn more in the Regions & Zones documentation.

Certain Compute Engine resources live in regions or zones. A region is a specific geographical location where you can run your resources. Each region has one or more zones. For example, the us-central1 region denotes a region in the Central United States that has zones us-central1-a, us-central1-b, us-central1-c, and us-central1-f.

Virtual machine Instances and persistent disks live in a zone, and these are referred to as zonal resources. For example, to attach a persistent disk to a virtual machine instance, both resources must be in the same zone.

First, let's create a Compute Engine virtual machine instance that only has a boot disk but no additional persistent disk storage.

In Cloud Shell, create a new virtual machine instance from the command line by using gcloud:

$ gcloud compute instances create gcelab --zone us-central1-c
Created [...].
gcelab us-central1-c n1-standard-1             10.240.X.X  X.X.X.X        RUNNING

The newly created virtual machine instance will have a default 10 GB persistent disk as the boot disk.

Google Compute Engine provides persistent disks for use as the primary storage for your virtual machine instances. Persistent disk storage is network storage that can be attached to virtual machine instances. Like physical hard drives, persistent disks exist independently of the rest of your machine – if a virtual machine instance is deleted, an attached persistent disk continues to retain its data and can be attached to another instance.

Create a new disk:

$ gcloud compute disks create mydisk --size=200GB \
  --zone us-central1-c
mydisk us-central1-c 5       pd-standard READY

Attaching the persistent disk

You can attach a disk to a running virtual machine. Let's attach the new disk to the virtual machine instance.

Attach the disk:

$ gcloud compute instances attach-disk gcelab \
  --disk mydisk --zone us-central1-c
Updated [].

That's it!

Finding the device in the virtual machine

The persistent disk is now available as a block device in the virtual machine instance. Let's take a look. First, SSH into the virtual machine:

$ gcloud compute ssh gcelab --zone us-central1-c
Warning: Permanently added 'X.X.X.X' (ECDSA) to the list of known hosts.

Let's find the disk device, it is located under /dev/disk/by-id/ as scsi-0Google_PersistentDisk_persistent-disk-1

username@gcelab:~$ ls -l /dev/disk/by-id/
lrwxrwxrwx 1 root root  9 Feb 27 02:24 google-persistent-disk-0 -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 27 02:24 google-persistent-disk-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Feb 27 02:25 google-persistent-disk-1 -> ../../sdb
lrwxrwxrwx 1 root root  9 Feb 27 02:24 scsi-0Google_PersistentDisk_persistent-disk-0 -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 27 02:24 scsi-0Google_PersistentDisk_persistent-disk-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Feb 27 02:25 scsi-0Google_PersistentDisk_persistent-disk-1 -> ../../sdb

Formatting and mounting the persistent disk

Once you find the block device, you can partition the disk, format it, and then mounting it. If you are familiar with Linux, you can easily use the utilities fdisk, mkfs, and mount.

First, make a mount point:

username@gcelab:~$ sudo mkdir /mnt/mydisk

Next, format the disk with a single ext4 filesystem using the mkfs tool. This command deletes all data from the specified disk:

username@gcelab:~$ sudo mkfs.ext4 -F -E \
  lazy_itable_init=0,lazy_journal_init=0,discard \

Finally, use the mount tool to mount the disk to the instance with the discard option enabled:

username@gcelab:~$ sudo mount -o discard,defaults \
  /dev/disk/by-id/scsi-0Google_PersistentDisk_persistent-disk-1 \

That's it!

Automatically mount the disk on restart

The disk will not be remounted if your virtual machine restarts. To make sure the disk is remounted on restart, you'll need to add an entry into /etc/fstab. Add below the line that starts with "UUID=...". You'll need to sudo to root to do this. An example is provided below:

username@gcelab:~$ sudo su -
username@gcelab:~$ echo \
  "/dev/disk/by-id/scsi-0Google_PersistentDisk_persistent-disk-1 /mnt/mydisk ext4 defaults 1 1" \
  >> /etc/fstab

Logout from Virtual Machine

Make sure you are logged out from the virtual machine by exiting from the shell by pressing the SSH disconnect sequence: [Enter][~][.].

Google Compute Engine can also attach local SSDs. Local SSDs are physically attached to the server hosting the virtual machine instance to which they are mounted. This tight coupling offers superior performance, with very high input/output operations per second (IOPS) and very low latency compared to persistent disks.

Local SSD performance offers:

These performance gains require certain trade-offs in availability, durability, and flexibility. Because of these trade-offs, local SSD storage is not automatically replicated and all data can be lost in the event of a host error or a user configuration error that makes the disk unreachable. Users must take extra precautions to backup their data.

This lab does not cover local SSDs. To maximize the local SSD performance, you'll need to use a special Linux image that supports NVMe. You can learn more about local SSDs in the Local SSD documentation.

You've learned about persistent disks and the key difference between persistent disks and local SSDs. You can easily use persistent disks to setup and configure your database servers.

What we've covered