When you attach a disk to a virtual machine (VM) that uses a Linux OS, Google Cloud automatically creates a symbolic link (symlink) for the disk. To access Persistent Disk volumes or Local SSD disks in your Linux VM, use the symlinks. These symlinks are predictable and remain consistent across reboots. Google Cloud creates symlinks for all disks attached to a VM in /dev/disk/by-id
.
This document explains how to identify the correct symlinks for the disks attached to a VM.
Limitations
If you attach Local SSD disks to a C3 or C3D VM, you might need to take additional steps to create the symlinks for the Local SSD disks. These steps are only required if you use any of the following public images offered by Google Cloud:
- SLES 15 SP4 and SP5
- SLES 12 SP4
These additional steps only apply to Local SSD disks; You don't need to do anything for Persistent Disk volumes.
The public images in the previous list don't have the Local SSD symlinks in /dev/disk/by-id/google-local-nvme-ssd-N
form. Only symlinks using the device information, for example nvme-nvme.1ae0-6e766d655f636172642d7064-6e766d655f636172642d7064-00000001
, exist on these images.
To get the user-friendly symlinks for these Linux images, you must update the udev
rules and add a script to the instance.
For instructions on updating the udev
rules to support symlinks for Local SSD disks on C3 and C3D, see Troubleshooting NVMe disks.
As an alternative to using symlinks, you can access the Local SSD disks on the VMs by using their device names, for example, /dev/nvme0n1
.
Format of symbolic links
Symlinks are created in /dev/disk/by-id
when a disk is attached to the VM, either during or after VM creation. The symlink names are created as follows:
Persistent Disk and Google Cloud Hyperdisk
The symlinks are created using the following rules:
- If you specified a custom device name when you created the disk:
google-DEVICE_NAME
- If you didn't specify a custom device name when you created the disk:
- Boot disk:
google-VM_NAME
- Non-boot disk:
google-DISK_NAME
- Boot disk:
After you format the disk, the symlink is appended with -partN
, where N is the partition number, for example google-data-disk-part1
.
Local SSD disks
Local SSD symlinks have different formats depending on the disk interface.
- SCSI:
- If you specified a custom device name when you created the disk:
google-DEVICE_NAME
- If you didn't specify a custom device name when you created the disk:
google-local-ssd-N
, where N is the Local SSD disk number, starting from 0.
- If you specified a custom device name when you created the disk:
- NVMe: The symlinks are named
google-local-nvme-ssd-N
, where N is the SSD number, starting from 0.
After you format a Local SSD disk, the symlink is appended with -partN
, where N is the partition number, for example, google-local-nvme-ssd-0-part1
.
Device symlinks
Compute Engine creates additional symlinks in the directory based on the disk type and interface, for example scsi-0Google_PersistentDisk_DEVICE_NAME
. These links perform the same function as the symlinks mentioned previously.
Example 1: C3 VM with attached Local SSD
Assume you created a VM with the following properties:
- VM name:
instance-1
- Machine series: C3
- Disk interface type: NVMe for both Persistent Disk and Local SSD
- Additional disks: none
- Attached Local SSD disks: 2
- Custom device names used: none
Compute Engine creates the following symlinks for that VM:
ls -l /dev/disk/by-id/google-*
google-instance-1 -> ../../nvme2n1 google-instance-1-part1 -> ../../nvme2n1p1 google-instance-1-part14 -> ../../nvme2n1p14 google-instance-1-part15 -> ../../nvme2n1p15 google-local-nvme-ssd-0 -> ../../nvme0n1 google-local-nvme-ssd-1 -> ../../nvme1n1
In this example, the Persistent Disk boot disk symlink is google-instance-1
, which is based on the VM name. The boot disk is formatted and has the operating system installed on it. The boot disk has 3 partitions: part1, part14, and part 15. The attached Local SSD disks are not formatted, so only a single symlink was created for each Local SSD disk.
Example 2: N2 VM with attached NVMe Local SSD and extra Persistent Disk
Assume you created a VM with the following properties:
- VM name:
instance-2
- Machine series: N2
- Disk interface type: SCSI for Persistent Disk and NVMe for Local SSD
- Additional disks: 1 Persistent Disk named
extra-scsi-disk
- Attached Local SSD disks: 2
- Custom device names used: none
The following symlinks are created for that VM:
ls -l /dev/disk/by-id/google-*
google-extra-scsi-disk -> ../../sdb google-instance-2 -> ../../sda google-instance-2-part1 -> ../../sda1 google-instance-2-part14 -> ../../sda14 google-instance-2-part15 -> ../../sda15 google-local-nvme-ssd-0 -> ../../nvme0n1 google-local-nvme-ssd-0-part1 -> ../../nvme0n1p1 google-local-nvme-ssd-1 -> ../../nvme0n2
In this example, the Persistent Disk boot disk symlink is google-instance-2
, which is based on the VM name. The boot disk is formatted and has the OS image installed on it. The boot disk has 3 partitions: part1, part14, and part 15. The first Local SSD disk is also partitioned, with a single partition, so there is an additional symlink created for that disk partition. The additional Persistent Disk added to the VM has the symlink google-extra-scsi-disk
, which is based the disk name. The extra Persistent Disk and second Local SSD disk are not formatted, so only a single symlink is listed for those disks.
What's next
- Learn how to use persistent device names.
- Format and mount your new disks on Linux or Windows VMs.
- Learn how to benchmark Persistent Disk performance.