resizeVolume of a running system VM's volume is accepted but the VM never sees the new size

Abierto Apto para principiantes
  • ¿Algo no está bien?
#14,645 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
backend, cloud

Línea de trabajo

Empieza con VolumeApiServiceImpl.orchestrateResizeVolume y sigue cómo identifica la VM y aplica las comprobaciones de estado existentes para el cambio de tamaño. Revisa las pruebas relacionadas con el cambio de tamaño de volúmenes que solo modifica el tamaño y con los estados de las VM del sistema; el cambio está terminado cuando se rechaza cambiar el tamaño de un volumen de una VM del sistema, salvo que la VM esté detenida, mientras que el cambio de tamaño de una VM detenida sigue funcionando.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

problem

A size-only resizeVolume of a running system VM's volume, for example a virtual router's ROOT, is accepted and resizes the volume on the storage. The running system VM is never told, so the guest keeps seeing the old size until it next starts. The API, the database and the storage all report the new size while the VM still runs on the old one.

VolumeApiServiceImpl.orchestrateResizeVolume only looks the VM up as a user VM (_userVmDao.findById). For a system VM that returns null, so the resize is sent with the instance name none and no host. On KVM the image is grown, but virsh blockresize is never run for the running domain. The per-hypervisor checks in the same method (XenServer can only resize a stopped VM's disk; on KVM the VM's host must be Up and Enabled) are skipped for the same reason.

Other paths already treat system VM volumes differently:

  • volume snapshots of system VM volumes are refused;
  • attach and detach accept only user VMs;
  • a ROOT resize through a new disk offering is refused unless the VM is Stopped.

The size-only path has no such check.

versions

4.22, and main.

The steps to reproduce the bug

Seen on KVM with Ceph RBD primary storage:

  1. Take a running virtual router whose ROOT disk offering is not size-strict.
  2. Call resizeVolume id=<router ROOT volume> size=<larger size in GB>.
  3. The call succeeds. listVolumes and rbd info show the new size.
  4. On the host, virsh domblkinfo <router> vda still shows the old size, and so does lsblk in the router. The new size only appears after the router is restarted.
What to do about it?

Refuse to resize the volume of a system VM that is not Stopped, with an error telling the admin to stop it first. Resizing it while it is stopped keeps working as before, and the VM sees the new size when it starts.

Doing the resize live instead would mean running the system VM's resize through the VM work queue and notifying the hypervisor, as is done for user VMs, and checking that on each hypervisor. Refusing is the smaller, safer change.

Lenguaje dominante
Java
Estrellas
3.1k
Forks
1.4k
Merge medio
6 d 20 h
PR fusionados (30 d)
17

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/cloudstack

Todos los issues de apache/cloudstack

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.