cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [cloudstack] andrijapanicsb opened a new issue #3779: [VMware / PVLAN] Port groups seem never cleaned up on ESXi when networks are deleted and thus block reusing the same VLANs (
Date Fri, 20 Dec 2019 09:38:44 GMT
andrijapanicsb opened a new issue #3779: [VMware / PVLAN] Port groups seem never cleaned up
on ESXi when networks are deleted and thus block reusing the same VLANs (
URL: https://github.com/apache/cloudstack/issues/3779
 
 
   
    * Bug Report
   
   ##### COMPONENT NAME
   <!--
   Categorize the issue, e.g. API, VR, VPN, UI, etc.
   -->
   ~~~
   Networking handling
   ~~~
   
   ##### CLOUDSTACK VERSION
   <!--
   New line separated list of affected versions, commit ID for issues on master branch.
   -->
   
   ~~~
   4.11+ (the issue is there probably from the very first days of  VMware support)
   ~~~
   Explanation of the problem with the steps to reproduce it:
   
   1. create a Shared network with i.e. VLAN 900, use it, delete it (spin a VM in the network,
delete the VM, delete the network) - and the port group created on ESXi host stays (as it
seems) forever and is never removed (at least not inside the time frame expected/set by network.gc.wait
and network.gc.interval). 
   
   On ESXi hosts, the port group with VLAN 900 is left existing forever.
   
   2. Now, create L2 network (as opposed to Shared created previously) with the same VLAN
900 - and ACS will silently reuse the same port group that already exists on vSphere- so far
so good. I assume its an expected behaviour since it seems that a (single VLAN i.e. not PVLAN)
port group has the same name when created for both Shared or L2 network - so we can silently
reuse the "garbage" port group without recreating it from scratch.
   
   **3. PROBLEM:** if you want to use the same VLAN 900 in the PVLAN setup (on shared or L2,
irrelevant) - ACS will try to create a NEW port group (due to different naming scheme for
the port group) by using the same Primary VLAN 900 (and some other secondary VLAN as defined
by PVLAN setup) but will fail to use VLAN 900 since it’s “used” by another port group
(even though we have previously deleted such networks in ACS).
   
   I’m testing with dvSwitches (required for PVLAN setup), if this info is of any relevance.
   
   In the related PVLAN work ( #3732 ) we are going to make checks which will simply block
the createNetwork API when any of the VLANs defined for the PVLAN setup (primary or secondary
VLANs) is already used on another ACS network. 
   But this doesn't solve the issue on "mature" environments, where a customer will upgrade
ACS, start using PVLANs, but he already has garbage port groups left from previous months/years
of his ACS infra existence.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message