Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
#13,966 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
74/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java

Rechercherichtung

Beginne mit NetworkOrchestrator.cleanupPersistentnNetworkResources() und networkMeetsPersistenceCriteria(), und vergleiche sie dann mit DefaultHostListener.setupPersistentNetwork() und hostAboutToBeRemoved(). Reproduziere den Löschablauf für persistente VXLAN-Netzwerke auf drei oder mehr Hosts und untersuche management-server.log und /sys/class/net/brvx-*; abgeschlossen ist es, wenn cleanup gesendet wird und Bridges und VXLAN-Schnittstellen von jedem Host verschwinden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Java
Sterne
3.1k
Forks
1.4k
Ø Merge
6 T. 20 Std.
Gemergte PRs (30 T.)
27

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/cloudstack

Alle Issues in apache/cloudstack

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.