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

Self-paced environment setup

If you don't already have a Google Account (Gmail or Google Apps), you must create one. Sign-in to Google Cloud Platform console ( and create a new project:

Remember the project ID, a unique name across all Google Cloud projects (the name above has already been taken and will not work for you, sorry!). It will be referred to later in this codelab as PROJECT_ID.

Next, you'll need to enable billing in the Developers Console in order to use Google Cloud resources like Cloud Datastore and Cloud Storage.

Running through this codelab shouldn't cost you more than a few dollars, but it could be more if you decide to use more resources or if you leave them running (see "cleanup" section at the end of this document). Prices are documented here: Cloud Datastore & Cloud Storage

New users of Google Cloud Platform are eligible for a $300 free trial.

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.

[[import using cloud shell]]

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 /dev/disk/by-id/scsi-0Google_PersistentDisk_persistent-disk-1

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 /mnt/mydisk

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=..." An example is provided below:

/dev/disk/by-id/scsi-0Google_PersistentDisk_persistent-disk-1 /mnt/mydisk ext4 defaults 1 1

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