A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://cloud.google.com/compute/docs/disks/disk-symlinks below:

Use symbolic links to access disks attached to a Linux VM | Compute Engine Documentation

Use symbolic links to access disks attached to a Linux VM

Stay organized with collections Save and categorize content based on your preferences.

Linux

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.

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:

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.

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:

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:

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

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Google Cloud automatically generates symbolic links (symlinks) in `/dev/disk/by-id` for all disks attached to a Linux virtual machine (VM), ensuring consistent access across reboots."],["Symlinks for Persistent Disks use the format `google-DEVICE_NAME`, `google-VM_NAME` (boot disk), or `google-DISK_NAME` (non-boot disk), while Local SSD symlinks are named `google-local-ssd-N` (SCSI) or `google-local-nvme-ssd-N` (NVMe), where N is the disk number."],["After formatting, a `-partN` suffix is added to the symlink name to represent the partition number of the disk."],["Specific Linux images like SLES 15 SP4/SP5 and SLES 12 SP4 on C3/C3D VMs might require extra steps to create user-friendly symlinks for Local SSD disks."],["You can use device names like `/dev/nvme0n1` as an alternative to using symlinks to access Local SSD disks."]]],[]]


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4