Home > Cloud Computing > Cisco UCS Director: Key Concepts Illustrated In Big Pictures

Cisco UCS Director: Key Concepts Illustrated In Big Pictures

During the last few months, I worked a lot with Cisco UCS Director on daily basis. As I wrote before, UCS Director is a powerful platform for you to manage and orchestrate infrastructures from VMware, Hyper-V, KVM, to the public clouds like Amazon, Azure.

Just like any other management platform, it abstracts the underlying infrastructure and operations using its own concepts and workflows. By exploring its Flex GUI, one can gradually get familiar with these concepts. It takes time to master a product, and no exception for UCS Director. Understanding key concepts and their relationships can help speed up the process significantly.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


In the following two sections, I will try to explain these concepts with two UML class diagrams. Unlike other UML class diagrams, my focus is not to show what attributes and methods in each class, but rather what key concepts/components are there, and how they are related to each other. The second part is very important for understanding a key concept because the role of a component is mostly defined how it’s associated with others. Without big pictures, it’s sometimes not easy to fully understand a key concept or component in short time.

Infrastructure Abstraction

There are a variety of infrastructures in a physical data center. To abstract these, Cloud is used as common concept for vSphere, Hyper-V, and etc. On top of a cloud, multiple VDCs (virtual data center) can be created. Unlike data center in vSphere, the VDC does not represent resources. Instead, it aggregates different aspects of policies, like compute, storage, network, system, cost model, and options for lease, self service etc. To find out what exactly in each policy, you can take a look at the GUI form where you can find all the details.


Associated with cloud is Catalog, which is essentially another name for virtual machine template. Because different cloud has its own virtual machine template format, the Catalog is cloud dependent. There could be multiple catalogs for one cloud.


Now, let’s take a look at the ownership of infrastructure. For that, the Group is used for group users in same organization. One Group can have zero to many VDCs, but any VDC must be owned by a Group.

For the Catalog, it’s much more flexible with many to many relationship. In other words, one group can have many Catalogs, and one catalog can belong to multiple Groups. This design allows re-use of Catalogs across multiple Groups.

Service Request

The infrastructure and policies are not the end. They are means for the end that serves users with various operations like deploying new virtual machines. This is accomplished by ServiceRequest.


To submit a service request, a user selects a catalog that is pre-defined in a Group it belongs to, and then picks a VDC to operate on.


I just illustrated some key concepts in UCS Director on infrastructure, ownership, and service request. Hopefully you will find it’s easier to learn and use UCS Director after reading this.

Should you need consulting on UCS Director, please feel free to reach out to me.

Categories: Cloud Computing Tags: , , ,
  1. May 27th, 2014 at 02:59 | #1

    The pictures are so powerful and explaining key facts and concepts in such a native way and they also conform my belief further on cisco UCE as the reliable innovator. Keep pouring such info, I am collecting it with both hands. Don’t worry, keep it coming.

  2. Yoram
    July 7th, 2014 at 06:52 | #2

    Steve, thanx much for this article. An eye opener.
    A couple of questions:

    1. Given the cardinalities that are depicted, a ServiceRequest can only be made in a scope of a particular VDC. the resulting service presumably is provisioned in the VDC against which the request was made. This means that UCSD does not entertain a possible migration of “services” among VDCs, not to mention Clouds. Is this a fair interpretation of your model?

    2. Can a User belong to multiple Groups? It’s hard for me to tell from the diagram

    3. I’m sure that there’s an implied constraint about the relationships between a User (within a Group), Catalogs and Clouds, but I need some clarification. Seems to me that you’re saying that Catalogs and groups are in many:many relationship but neither can exist independently. What is the constraint on this relationship? Next, a Group may be associated with any number of VDCs, but can those VDCs belong to different Clouds? In other words: can a Group be indirectly associated with multiple Clouds?

    4. In your diagram there’s a 1:1 relationship between a ServiceRequest and a VDC. Can this be right? A VDC cannot exist unless a ServiceRequets is associated with it?

    5. I’m not sure I understand the relationship between a Catalog and Servicerequest. The Diagram has ‘1’ but this leaves one end with no specified cardinality (I assume that a Catalog must exist but a ServiceRequest is optional. Also, I’d expect that there would be multiple ServiceRequests allowed per catalog…

    awaiting your answers.
    Much thanx!


  1. No trackbacks yet.