Page History

...

Architecture and Design description

...

•CloudStack assumes dvSwitch is already created in customer's datacenter. This ensures CloudStack's doesn't have to deal with dynamic migration of virtual adapters or networks across other vSwitch. As co-existance of multiple types of virtual switches like Cisco's Nexus 1000v or VMware standard vSwitch and dvSwitch makes it difficult for configuration. Instead administrator can decide where to configure which type of network etc. or migration (say from vSwitch to dvSwitch) and does it with more reliably.
•Highlight architectural patterns being used (queues, async/sync, state machines, etc) - N/A
•Talk about main algorithms used•VLAN configuration over dvSwitch (as we are doing with vSwitch right now)
•The scenarios to be covered are,•Adding host/compute resource to podcluster
•Iterate through the configuration specs (management dvPortGroup – with name prefix as “cloud.private”)and configure & prepare cloud networks on dvSwitch
•Livemigration
•VM life cycle operations which might need instantiation of guest network etc.
•Network operations like network shutdown, network creation, network destroy etc.

•Port binding would be static binding.
•Create dvPortGroup with open dvPorts

•Explain what components are being changed and what the dependent components are
•VmwareResource and VmwareManager (server)
•Regarding database: talk about tables being added/modified - N/A
•Performance implications: what are the improvements or risks introduced to capacity, response time, resources usage and other relevant KPIs•In vSphere 5.0, we will use "AutoExpand" support to configure dvPorts per dvPortGroup. This ensures that we don't pre-allocate unnecessary dvPorts so that they exhaust quicker.

•Preferably show class diagrams, sequence diagrams and state diagrams - N/A
•If possible, publish signatures of all methods classes and interfaces implement, and the explain the object information of different classes
•core package (VmwareManager, VmwareResource)
•server package
•vmware-base package mo and util packages

• highlight architectural patterns being used (queues, async/sync, state machines, etc)
• talk about main algorithms used
• explain what components are being changed and what the dependent components are
• regarding database: talk about tables being added/modified
• performance implications: what are the improvements or risks introduced to capacity, response time, resources usage and other relevant KPIs
• preferably show class diagrams, sequence diagrams and state diagrams
• if possible, publish signatures of all methods classes and interfaces implement, and the explain the object information of different classes

...