Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

VXLAN persistent networks create bridges on hosts that never ran a VM on them, but don't clean them up

Abierto
#13,966 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java

Línea de trabajo

Comienza con NetworkOrchestrator.cleanupPersistentnNetworkResources() y networkMeetsPersistenceCriteria(), y luego compáralos con DefaultHostListener.setupPersistentNetwork() y hostAboutToBeRemoved(). Reproduce el flujo de eliminación de una red VXLAN persistente en tres o más hosts e inspecciona management-server.log y /sys/class/net/brvx-*; se considera terminado cuando se envía cleanup y los bridges y las interfaces VXLAN desaparecen de todos los hosts.

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

Descripción

bug
problem

With a persistent network offering, CloudStack builds the network's bridge on every host in the zone. But when the network is deleted it only cleans the bridge up on hosts that actually ran a VM on it. On every other host, the bridge and its VXLAN interface stay behind forever.

Investigation
There is a difference between the filters when creating a persistent network, and removing a persistent network.
Creation:
DefaultHostListener.setupPersistentNetwork() creates the bridges on hostConnect/hostEnabled for all networks from getAllPersistentNetworksFromZone() - no isolation-method filter.
Removal:
NetworkOrchestrator.cleanupPersistentnNetworkResources() is gated by networkMeetsPersistenceCriteria(), which requires the broadcast URI scheme to be Vlan, so for vxlan:// networks CleanupPersistentNetworkResourceCommand is never sent. (hostAboutToBeRemoved() sends the same cleanup with no scheme check either - the VLAN-only gate exists only on the network-delete path.)

Hosts that ran a VM on the network are cleaned up via the normal VM-lifecycle teardown, so the leak only affects uninvolved hosts.

versions

4.22.1.1, KVM, advanced zone with VXLAN isolation, persistent network offerings.

The steps to reproduce the bug
  1. Advanced zone, KVM, VXLAN isolation, 3+ hosts.
  2. Create a VPC with two tiers on a persistent offering.
  3. Start VMs so they land on only some hosts. (Restarting cloudstack-agent on an uninvolved host also creates the bridges there via hostConnect.)
  4. Delete the tiers, then the VPC.
  5. ls -d /sys/class/net/brvx-* on each host.

Expected behaviour:
The bridge and VXLAN interface are removed from every host in the zone.

Actual behaviour:
The VNI is still present on hosts that never ran a VM on the network; CleanupPersistentNetworkResourceCommand never appears in management-server.log during the delete.

What to do about it?

Accept Vxlan alongside Vlan in networkMeetsPersistenceCriteria(), or drop the scheme check to match the setup path.

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

Guía de contribución

Abrir la guía de contribución

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.