Usa vínculos simbólicos para acceder a los discos conectados a una VM de Linux

Cuando conectas un disco a una máquina virtual (VM) que usa un SO Linux, Google Cloud crea automáticamente un vínculo simbólico (symlink) para el disco. Para acceder a los volúmenes de Persistent Disk o a los discos SSD locales en tu VM de Linux, usa los symlinks. Estos symlinks son predecibles y se mantienen coherentes en los reinicios. Google Cloud crea symlinks para todos los discos conectados a una VM en /dev/disk/by-id.

En este documento, se explica cómo identificar los symlinks correctos para los discos conectados a una VM.

Limitaciones

Si conectas discos SSD locales a una VM C3 o C3D, es posible que debas realizar pasos adicionales para crear los symlinks de los discos SSD locales. Estos pasos solo son obligatorios si usas cualquiera de las siguientes imágenes públicas que ofrece Google Cloud:

  • SLES 15 SP4 y SP5
  • SLES 12 SP4

Estos pasos adicionales solo se aplican a los discos SSD locales; no necesitas hacer nada para los volúmenes de Persistent Disk.

Las imágenes públicas de la lista anterior no tienen los symlinks de SSD locales en formato /dev/disk/by-id/google-local-nvme-ssd-N. En estas imágenes, solo existen symlinks que usan la información del dispositivo, por ejemplo, nvme-nvme.1ae0-6e766d655f636172642d7064-6e766d655f636172642d7064-00000001.

Para obtener los symlinks fáciles de usar para estas imágenes de Linux, debes actualizar las reglas udev y agregar una secuencia de comandos a la instancia.

Si deseas obtener instrucciones para actualizar las reglas udev para admitir symlinks para discos SSD locales en C3 y C3D, consulta Soluciona problemas de discos NVMe.

Como alternativa al uso de symlinks, puedes acceder a los discos SSD locales en las VMs mediante sus nombres de dispositivo, por ejemplo, /dev/nvme0n1.

Los symlinks se crean en /dev/disk/by-id cuando se conecta un disco a la VM, durante o después de su creación. Los nombres de los symlinks se crean de la siguiente manera:

Persistent Disk y Google Cloud Hyperdisk

Los symlinks se crean con las siguientes reglas:

  • Si especificaste un nombre de dispositivo personalizado cuando creaste el disco: google-DEVICE_NAME
  • Si no especificaste un nombre de dispositivo personalizado cuando creaste el disco:
    • Disco de arranque: google-VM_NAME
    • Disco que no es de arranque: google-DISK_NAME

Después de formatear el disco, el symlink se agrega con -partN, en el que N es el número de partición, por ejemplo, google-data-disk-part1.

Discos SSD locales

Los symlinks de SSDs locales tienen diferentes formatos según la interfaz de disco.

  • SCSI: Los symlinks se denominan google-local-ssd-N, en los que N es el número de disco SSD local, que comienza en 0.
  • NVMe: Los symlinks se denominan google-local-nvme-ssd-N, en los que N es el número de SSD, que comienza en 0.

Después de formatear un disco SSD local, el symlink se agrega con -partN, en el que N es el número de partición, por ejemplo, google-local-nvme-ssd-0-part1.

Symlinks de dispositivos

Compute Engine crea symlinks adicionales en el directorio según el tipo de disco y la interfaz, por ejemplo, scsi-0Google_PersistentDisk_DEVICE_NAME. Estos vínculos realizan la misma función que los symlinks mencionados antes.

Ejemplo 1: VM C3 con SSD local conectado

Supongamos que creaste una VM con las siguientes propiedades:

  • Nombre de la VM: instance-1
  • Serie de máquinas: C3
  • Tipo de interfaz de disco: NVMe para Persistent Disk y SSDs locales
  • Discos adicionales: Ninguno
  • Discos SSD locales conectados: 2
  • Nombres de dispositivos personalizados utilizados: ninguno

Compute Engine crea los siguientes symlinks para esa 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

En este ejemplo, el symlink del disco de arranque del Persistent Disk es google-instance-1, que se basa en el nombre de la VM. El disco de arranque está formateado y tiene instalado el sistema operativo. El disco de arranque tiene 3 particiones: parte 1, parte 14 y parte 15. Los discos SSD locales conectados no tienen formato, por lo que solo se creó un symlink para cada disco SSD local.

Ejemplo 2: VM N2 con SSD local NVMe conectado y Persistent Disk adicional

Supongamos que creaste una VM con las siguientes propiedades:

  • Nombre de la VM: instance-2
  • Serie de máquinas: N2
  • Tipo de interfaz de disco: SCSI para discos persistentes y NVMe para SSD locales
  • Discos adicionales: 1 Persistent Disk llamado extra-scsi-disk
  • Discos SSD locales conectados: 2
  • Nombres de dispositivos personalizados utilizados: ninguno

Se crean los siguientes symlinks para esa 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

En este ejemplo, el symlink del disco de arranque del Persistent Disk es google-instance-2, que se basa en el nombre de la VM. El disco de arranque tiene un formato y tiene la imagen de SO instalada. El disco de arranque tiene 3 particiones: parte 1, parte 14 y parte 15. El primer disco SSD local también está particionado, con una sola partición, por lo que se crea un symlink adicional para esa partición de disco. El Persistent Disk adicional que se agrega a la VM tiene el symlink google-extra-scsi-disk, que se basa en el nombre del disco. El Persistent Disk adicional y el segundo disco SSD local no tienen formato, por lo que solo se enumera un symlink para esos discos.

¿Qué sigue?