Bug Reference
CLOUDSTACK-6104
Branch
Apache CloudStack master branch
Introduction
Isolation of VM Traffic is achieved using Security Groups in Basic Zones. For Advanced zone, traffic can be isolated on a per network basis using VLANs. Advanced Zones support shared as well as isolated networks. Currently, there is no way to isolate guest traffic within a network. There is another similar requirements document for SG support in advanced zone for XS and KVM.
Another way of supporting isolation within a guest network is using PVLANs. This requirements document captures the requirement related to adding PVLAN support. For VMWare Hypervisor, since the classic SG support can't be added, one of the solutions would be to support PVLANs (Private VLANs) for this solution.
Purpose
This is functional specification of feature "PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment" which has Jira ID CLOUDSTACK-6104.
References
Use Cases
Customers / Users have asked for the following requirements across all Hypervisors.
- Isolation within a network: Shared Networks can be created with different levels of scope. It can be shared within an account, domain, project or a global shared network. With multiple users deploying VMs on a shared network, users might want to control traffic on their VMs based on Security groups.
- Isolation across multiple networks: Some customers might deploy multiple shared networks and they might need to restrict communication not only within a network but also across different networks. For example, user A could have VM1 in Network 100 and VM2 in Network 200 but they might want to limit the communication on these VMs to just talk to each other and a limited set of Public IP Addresses.
- VMs deployed using multiple Networks: There could be various cases in which a VM is deployed on two networks (an isolated network for the account and a common shared network providing monitoring capabilities). In these cases, admins will want to limit the communication between different tenants who are sharing the common shared Network.
- Isolated Network: With Isolated Networks (including VPC), users can deploy multiple applications on the same isolated Network or same VPC. Users might want to prevent communication between the applications within the same Network/VPC.
The most common requirement is for customers to run multiple Shared Networks to offer various services like monitoring, patching, etc. Although, not all of the requirements can be met with PVLAN support, this basic requirement could be addressed with CS enabling the PVLAN support.
Customer Benefits:
- Allowing users to control traffic within a network would help them deploy multiple applications without communication between application as well as prevent communication with other users’ VMs.
Feature Specifications
- Currently PVLAN support is available in CloudStack deployment over VMware ESXi hypervisor for VMware dvSwitch only. This needs to be extended to Cisco Nexus 1000v as well.
- Quality risks (test guidelines)
- Test all use cases mentioned above.
- Test high number of PVLANs with multiple shared networks as well.
- specify supportability characteristics:
- Management server log would be written with messages indicating the PVLAN configuration status and associated Nexus 1000v switch being configured.
- To debug the issues specific to this feature, administrator should check following,
- Nexus 1000v CLI - To check PVLAN setup/configuration over port profiles
- vCenter (vSphere client) - To check membership of VM's vNics to distribtued port groups
- CloudStack UI/DB - To check information about instances, isolated networks and PVLAN primary/secondary IDs
- Deployment requirements (fresh install vs. upgrade) if any
- This feature is supported in fresh install as well as upgrade. PVLAN configuration would be applicable only in case of virtual networks implemented over Cisco Nexus 1000v only.
- Interoperability and compatibility requirements:
- Performance & scalability implications when feature is used from small scale to large scale
- Target user details
- This feature is mainly targeted for administrators
Arhitecture and Design description
- PVLAN support is already implemented for CloudStack deployments over VMware ESXi but it is done only for VMware distributed virtual switch. Leveraging the existing framework to support PVLAN, adding resource specific changes to setup/configure PVLAN over Cisco Nexus 1000v should ensure the support is extended.
- New functions to add primary and secondary VLANs to port groups, and to be called in HypervisorHostHelper.java, will need to be added to VsmCommand.java and NetconfHelper.java.
Limitations
API
These changes are already in ACS introduced as part of PVLAN support for KVM and VMware (VMware dvSwitch).
PVLAN can be enabled on shared networks. Shared networks are created by admin users, end user vms are allowed to have nics on shared networks.
Modify createNetworkCmd (for shared networks)
- Add a new parameter: isolatedpvlan:
- Not a required paramter. if the parameter is not null, then PVLAN would be enabled.
- When the parameter is set, it must be advance shared network.
DB Schema
No changes
UI flow
- The admin creates a shared vlan. She is asked if it is a PVLAN. If yes, in addition to the primary vlan id, she is asked for the secondary vlan id.
The pre-confirmation dialog asks her to make sure her physical infrastructure is configured in the same fashion.