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

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#14,645 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
java
Domaine
backend, cloud

Piste de recherche

Commencez par VolumeApiServiceImpl.orchestrateResizeVolume et suivez la façon dont la VM est identifiée et dont les contrôles d’état existants pour le redimensionnement sont appliqués. Vérifiez les tests associés au redimensionnement de volumes portant uniquement sur la taille et aux états des VM système ; la modification est terminée lorsque le redimensionnement d’un volume d’une VM système est refusé à moins que la VM soit arrêtée, tandis que le redimensionnement d’une VM arrêtée continue de fonctionner.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Java
Étoiles
3.1k
Forks
1.4k
Merge moyen
6 j 20 h
PR mergées (30 j)
17

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/cloudstack

Toutes les issues de apache/cloudstack

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.