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

Cuando conectas un disco a una máquina virtual (VM) que usa un SO de Linux, Google Cloud crea de forma automática un vínculo simbólico (symlink) para el disco. Para acceder a los volúmenes de Persistent Disk o los discos SSD locales en tu VM de Linux, usa los symlinks. Estos symlinks son predecibles y permanecen coherentes en todos 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 este recurso. Discos SSD. Estos pasos solo son necesarios 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. Solo hay symlinks que usan la información del dispositivo, por ejemplo, nvme-nvme.1ae0-6e766d655f636172642d7064-6e766d655f636172642d7064-00000001, en estas imágenes.

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 un disco se conecta a la VM, ya sea durante o después de la creación de la VM. Los nombres de symlink 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 personalizado del dispositivo cuando creaste el disco, sigue estos pasos:
    • 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 SSD locales tienen diferentes formatos según la interfaz del disco.

  • SCSI: Los symlinks se llaman google-local-ssd-N, en los que N es el número del disco SSD local, a partir de 0.
  • NVMe: Los symlinks se llaman google-local-nvme-ssd-N, en los que N es el número SSD, a partir de 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 del dispositivo

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 que se mencionaron 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 SSD local
  • Discos adicionales: ninguno
  • Discos SSD locales conectados: 2
  • Nombres de dispositivos personalizados usados: 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 el sistema operativo instalado. El disco de arranque tiene 3 particiones: parte1, parte14 y parte 15. Los discos SSD locales conectados no tienen formato, por lo que se creó solo 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 Persistent Disk y NVMe para SSD local
  • Discos adicionales: 1 Persistent Disk llamado extra-scsi-disk
  • Discos SSD locales conectados: 2
  • Nombres de dispositivos personalizados usados: 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 formato y tiene la imagen de SO instalada. El disco de arranque tiene 3 particiones: parte1, parte14 y parte 15. El primer disco SSD local también se particiona con una sola partición, por lo que hay un symlink adicional creado 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?