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

  • N/A

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.

 

  • No labels