VCAP-CID Study Notes: Objective 2.1

This is Objective 2.1 in the VCAP-CID blueprint Guide 2.8. The rest of the sections/objectives can be found here.

Bold items that have higher importance and copied text is in italic.


  • Identify what can be included in a published catalog.
    • A vCloud Catalog can include several things, most of them vApps of various sizes and ISO files.
      • vApp with one VM.
      • vApp with several VM’s with various level of connection between them.
      • Media files: ISO files for the installtion of new VM’s OS inside a vApp. Floppy disks are also supported. Please note that users will not see the media files unless a Organization admin moves them to their Organization Catalog and shares them with the users.
    • A Published Catalog or a Global Catalog is a catalog where a vCloud admin has made a certain catalog public to all organization in the cloud.
  • Identify what can be included in a private catalog.
    • Same things you can in a published catalog.
    • But you will need to have access to the catalog to be able to create VM’s from it.
  • Identify permission controls for catalogs.
    • This picture is snapped from the vCloud Director Users Guide and says it all:
    • VCAP CID 2-1-1
  • Explain the functionality of a catalog.
    • The best way to explain what a catalog is is to quote the VCAT Consuming a VMware vCloud documentation:
    • Organizations can offer the following types of service catalogs to their users or customers:
      • A vCloud service catalog – Includes predefined vApps, virtual machines, and images (operating systems and applications) that users can deploy within an organization
      • An operational service catalog – Includes operational features such as development of a vCloud service catalog, backup and recovery services, archival services, managed services, and migration services.
    • And then a quote from the vCloud Director User’s Guide:
      • A catalog is a container for vApp templates and media files in an organization. Organization administrators and catalog authors can create catalogs in an organization. Catalog contents can be shared with other users in the organization and can also be published to all organizations in the vCloud Director installation.
      • There are two types of catalogs in vCloud Director; organization catalogs and public catalogs. Organization catalogs include vApp templates and media files that you can share with other users in the organization. If a system administrator enables catalog publishing for your organization, you can publish an organization catalog to create a public catalog. Organization administrators from any organization in the vCloud Director installation can view the vApp templates and media files in a public catalog and copy those files to a catalog in their organization for use by their members.
      • There are two ways to add vApp templates to a catalog. You can upload an OVF package directly to a catalogor save a vApp as a vApp template.
      • Members of an organization can access vApp templates and media files that they own or that are shared to them. Organization administrators and system administrators can share a catalog with everyone in an organization, or with specific users and groups in an organization.

Skills and Abilities

  • Based on application requirements, determine appropriate vApp configuration.
    • Lets start with a short introduction to what a vApp is:
      • A vCloud vApp differs from a vSphere vApp in the way it is instantiated and consumed in the vCloud. A vApp is a container for a distributed software solution and is the standard unit of deployment in vCloud Director. It allows power-on and -off operations to be defined and ordered, consists of one or more virtual machines, and can be imported or exported as an OVF package. A vCloud vApp can have additional vCloud-specific constructs such as networks and security definitions.
    • A vApp can contain a single VM or multiple VM’s that can have various interconnections between them.
    • If using single VM vApps the usual VM design considerations apply
      • Single vCPU unless needed
      • Newest VMware tools
      • Don’t use Reservations and limits unless the design requires it.
      • Use VMXNET3 where supported
      • Secure VM’s like you would physical machines
      • Use naming conventions.
    • Lets say you have a Database, it needs more then 32 vCPU, you should upgrade the virtual hardware version to at least 9.
  • Determine appropriate storage configuration for a given vApp.
    • This most likely is related to where a VM in a vApp should reside.
    • Let’s say a vCloud installation has 3 tiers of storage, Gold, Silver and Bronze. You can select which VM should use each tier. So a database VM should likely go to a Gold tier, while a Development machine would use the Bronze tier.
  • Given customer requirements, determine appropriate catalog design.
    • A Catalog can include vApps, and media files. Access to those catalogs can be controlled.
  • Determine the impact of given security requirements, on a catalog structure.
    • The only sequrity feature with catalog structure is permissions. You can make the changes you need so only a subset of people/deparment can access certain catalogs.

VCAP-CID Study Notes: Objective 1.2

This is Objective 1.2 in the VCAP-CID blueprint Guide 2.8. The rest of the sections/objectives can be found here.

Bold items that have higher importance and copied text is in italic.


  • Identify discovery questions for a conceptual design (number of users, number of VMs, capacity, etc.)
    • First we need to know what a conceptual design is.
      • A conceptual design is a high level overview of a design. It includes how the design will eventually look like or a final look of the design. It should show the concepts the design will cover. In a vCloud environment it might include different Tiers of Resource clusters, a different Management cluster, information on the various clusters (replication, storage stacks, networking, security).
      • Conceptual vCloud
    • When we have an idea what a conceptual design should include, we need to ask the right groups within the organization to fill in the blanks, and these groups include various roles:
      • C-level IT people – who are more aligned with the business side of IT
      • Server Administrators – those who manage the hardware resources, CPU and Memory.
      • Storage Administrators – those who manage storage, both hardware and creating logical storage for utilization (the manual way)
      • Backup Administrators
      • Desktop Administrators
      • Network Administrators
      • Security Administrators
      • Virtualization Administrator
      • Application Power users and/or administrators – great in use-case creation
      • Help desk – these know more than most Level 3 Support guys on what is the real issue with some environment.
      • End users – in use-case creation, and to find out the paint points of the current operational model.
    • The questions can both cover the current environment and the future environment and of course regarding the projected usage of the environment:
      • How many users will be accessing each service? (used for scalability and capacity considerations)
      • How many VM’s are you currently using? (used for current capacity considerations)
      • What is the projected growth rate of VM’s? (used for future capacity considerations)
      • Are there any security requirements? (Compliance, isolation (data, network etc), mobility)
      • What are the current layout of performance tiers in the environment? (used for current performance considerations)
      • Are there plans to offer different performance tiers based workloads? (used for future performance considerations and SLA requirements)
      • Are there requirements for DR/BC? If so would they vary between performance tiers?
  • Identify the effect of product architecture, capabilities, and constraints on a conceptual design.
    • This is a very vague point, but I guess they mean how the different products in the vCloud stack, with their abilities and constraints, and how they affect the creation of the conceptual design.
    • I guess you would use your knowledge of vCloud environment architecture to create the conceptual design using the business requirements you have been given.
    • The product, VMware vCloud, will have constraints on how the conceptual design will be. Even if the business requirements are somewhat different they can’t go beyond what the actual product can do.
    • It this process of gathering the requirements from the business to translate them into a working conceptual design that is part of the process.

Skills and Abilities

  • Relate business and technical requirements to a conceptual design.
    • Business requirements are all about value, or how the design should provide value to the business. To name a few that could be used is:
      • Self-service capability
      • 99.9 % availability
      • Scalability
      • Multitenancy
      • Metering Capabilities
    • Technical requirements are just how you will use the technology in question to fulfill those business requirements
    • VCAP CID Obj 1.2 - 2
    • The technical requirements also include stuff that are not easily tracked to a certain business requirement and is more of a logical layout of the design:
      • Storage requirement: Different Tiers of storage must be available to the customer (T1,T2,T3)
      • Storage requirement: NFS datastore for the vCloud cell
      • Security requirement: AD must be used to authenticate users to the vCloud environment
  • Gather customer inventory data.
    • This can be done in multiple ways and that really depends on the project itself.
    • When the plan is to import existing workload into vCloud you will need some capacity information. You can use Capacity Planner, which is a tool VMware Partners get access to.
    • If you need to see the financial benefit of moving to the vCloud Suite you ask VMware Partners to use VMware Infrastructure Planner tool. It can be located here :
    • Also if the customer has inventory document ready and capacity and performance information as well that can also be used.
  • Determine customer business goals.
    • Like I stated before a business requirement can be described as what needs to be achieved for the system to provide value. Here are some examples ofvCloud specific business requirements:
      • System must provide self-service capability
      • System must provide 99.9% availability
      • System must provide optimal scalability and elasticity
      • System must provide multitenancy
      • System must provide metering capabilities for cost reporting
      • System must support vApp use cases defined
      • System must leverage shared infrastructure and resources pooling
      • System must support a catalog of templates that end users can create
      • System must provide differentiated offerings based on cost.
      • The last 4 are taken from the Cloud Infrastructure Use Case document. They are somewhatvSphere related, but are they are a great example.
        • Business agility and flexibility should be increased; the cost of doing business should be decreased.
        • Minimal workload deployment time.
        • The environment should be scalable to enable future expansion (minimum one year, 20 percent estimated).
        • Resources should be guaranteed to groups of workloads as part of internal SLAs
      • The business requirements are not something that is handed to the architect as a list of things they solution must fulfill, but a list of requirements that are agreed upon during the design phase interviews. The architect must help the customer define the business requirements based on the capabilities and constraints of the product itself or you could end up with conflicting or even out-of-scope requirements.
  • Identify requirements, constraints, risks, and assumptions.
    • The majority of the next lines are straight from the vCloud Service documents available to VMware Partners.
    • Requirements are documented statements that depicts the requisite attributes, characteristics or qualities of the system
      • See business and technical requirements above for examples.
    • Constraints are requirements that restrict the amount of freedom in developing the design.
      • Existing hardware must be used
      • Distance between Datacenters
      • Cost
      • Network bandwidth is 1Gbps
      • Total storage available is 10TB
      • Etc…
    • Risks are potential issues that may negatively impact the reliability of the design
      • Lack of redundancy of specific hardware component
      • Support staff has not had any training
      • If hardware is not installed and configured by expected date, the project timeline will be affected
    • Assumptions are “educated guesses” that are made during the design process regarding the expected usage and implementation of a system. You should try to mitigate the assumptions by explaining them or even changing them to a requirement by asking the customer about the assumption.
      • Redundant hardware components are used
      • Training is provided for staff
      • Sufficient bandwidth is available for the projected number of VMs
      • All licences are ready before the implementation phase
    • Lets use Training as an example assumption. You as an architect assume the customer will provide training. You could leave it at that or ask the customer and verify that training will performed and change it to a requirement (Management requirement). An unresolved assumption (or at least unexplained one) will always have risks associated with it, like in this case if the customer wouldn’t train their staff there is a risk the project could fail.
  • Given customer requirements and product capabilities, determine the impact to a conceptual design.
    • I think this have already been covered in this post. The requirements of the customers must be related to the capabilities of the product and that will impact the conceptual design.

VCAP-CID Study Notes: Objective 1.1

This is Objective 1.1 in the VCAP-CID blueprint Guide 2.8. The rest of the sections/objectives can be found here.

Bold items that have higher importance and copied text is in italic.

Skills and Abilities

Distinguish between virtualization, automation and cloud computing.

  • Virtualization is basic virtualization of services or applications. Instead of running it on physical machine it is run on a virtual machine on top of hypervisor. At most you have multiple hypervisors (ESXi hosts) in a cluster, managed by a management service (vCenter). Installing new services still require manual work of installing a operating system (OS), either by installing, or by creating from templates, and then installing the application on top of the OS.
  • Automation is a way to automate know workflows, eg. A script that creates a new VM from a template, updates the network config, adds it to a domain, and maybe in some cases installs a application on said VM. There is no real cost analysis, service agreements behind the automation process itself. Just putting some otherwise manual processes together in a script/workflow.
  • Cloud computing is way to change IT to be more service oriented. Instead of focusing on VM’s it has a new focus on services that run on the VM’s. If you compare normal virtualization and simple automation to cloud computing, you can say that cloud computing includes both virtualization and automation but with the goal of further improve cost effciency , quality of service and business agility. What cloud computing services need to offer has been defined by the NIST (National Institute of Standards and Technology):
    • Broad network access – Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin client or thick client platforms.
    • Rapid elasticity – Capabilities can be provisioned to scale out quickly and to be released rapidly—in some cases, automatically. Rapid elasticity enables resources to both scale out and scale in quickly. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
    • Measured service – Cloud systems automatically control and optimize resource usage by leveraging a metering capability at some level of abstraction appropriate to the type of service. Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and the consumer of the utilized service.
    • On-demand self-service – A consumer can unilaterally automatically provision computing capabilities as needed without requiring human interaction with each service’s provider.
    • Resource pooling – The provider’s computing resources are pooled to serve multiple consumers, using a multitenant model with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. A sense of location independence results because the subscriber generally has no knowledge of or control over the exact location of the provided resources, but the subscriber might be able to specify location at a higher level of abstraction.
  • Just to include what VMware believes a IaaS require (from the vCAT Introduction document):
    • A cloud must be built on a pooled, virtual infrastructure. Pools include not only CPU and memory resources, but also storage, networking, and associated services.
    • The cloud should provide application mobility between clouds, allowing the consumer to enter and leave the cloud easily with existing workloads. The ability to use existing consumer tools to migrate workloads to or from the cloud is highly desirable. Mobility of workloads between clouds requires cross-cloud resource management.
    • The cloud should be open and interoperable, allowing the consumption of cloud resources over open, Internet-standard protocols. Access to cloud resources does not require any other specific network protocols or clients.
    • Cloud consumers should pay only for resources they consume or commit to consuming.
    • The cloud should be a secure, trusted location for running cloud consumer workloads.
    • Cloud consumers should have the option and capability to protect their cloud-based workloads from data loss.
    • Cloud consumers are not responsible for maintaining any part of the shared infrastructure and do not need to interact with the cloud provider to maintain the infrastructure. They are not responsible for storage and network maintenance, ongoing cloud infrastructure patches, or business continuity activities. The cloud should be available to run high-availability workloads, and any faults occurring in the cloud infrastructure should be transparent to cloud consumers as a result of built-in availability, scalability, security, and performance guarantees.

Distinguish between private, public, hybrid and community cloud computing.

  • The VMware vCloud Architechture Toolkit (vCAT) Service Defenitions document has this covered:
    • Private vCloud – The vCloud infrastructure is operated solely for an organization and can be managed by the organization or a third party. The infrastructure can be located on-premises or off-premises.
    • Public vCloud – The vCloud infrastructure is made available to the general public or to a large industry group and is owned by an organization that sells vCloud services.
    • Hybrid vCloud – The vCloud infrastructure is a composite of two or more vCloud instances (private and public) that remain unique entities but are bound together by standardized technology. This enables data and application portability, such as cloud bursting for load balancing between vCloud instances. With a hybrid vCloud, an organization gets the advantages of both, with the capability to burst into the public vCloud when needed while maintaining critical assets on-premises.
    • Community vCloud – Several organizations share the vCloud infrastructure. The infrastructure supports a specific community that has shared concerns, such as mission, security requirements, policy, and compliance considerations. It can be managed by the organizations or a third party and can be located on-premises or off-premises.
  • But I really like to include the defenition in the vCAT Introduction document as well as it is even more detailed and explanatory:
    • Private cloud:
      • A private vCloud (also known as an internal vCloud.) operates on private networks, where a single company maintains accessible resources behind the firewall. In many cases, all the tenants share one legal entity. For example, a university might offer IaaS to its medical and business schools, or a company might do the same for various groups or business units. The private vCloud can be managed by the enterprise and hosted on-premise or operated on a dedicated infrastructure provided by a vCloud service provider or systems integrator. In any case, a private vCloud must conform to the organizational security constraints.
    • Public cloud:
      • A public vCloud offers IT resources as a service through external service providers and is shared across multiple organizations or the Internet. This can be viewed as a vCloud infrastructure that one organization operates and that multiple, legally separated organizations use.
      • A public vCloud is provisioned for open access and might be owned, managed, and operated by one or more entities.
      • A public vCloud provider might also support a private, community, or hybrid vCloud.
    • Hybrid cloud:
      • A hybrid vCloud combines the benefits of the private and the public vCloud, with flexibility and choice of deployment methods.
      • A hybrid vCloud consists of multiple, linked vCloud infrastructures. These distinct vCloud infrastructures can be private, community, or public; but they must meet a set of requirements that the providers define and the consumers agree to. Connecting these vCloud instances requires data and application mobility, as well as management.
      • When load-balancing between vCloud instances (cloud bursting), use a consistent monitoring and management approach when migrating an application or data workload. For the theory behind cloud bursting, see the Cloud Bursting document.
    • Community cloud:
      • A community vCloud is a specific public vCloud use case in which the cloud is shared, and typically owned, by a group of organizations with a common set of requirements. In many cases, the organizations also include some level of legal separation. Community vCloud resources are shared, with some parts under central control and other parts with defined autonomy. A vCloud built for government, education, or healthcare is an example of a community vCloud.
      • A community vCloud can be offered by a traditional service provider, by a member of the community, or by a third-party vendor and hosted on one or more sites. It can be placed on-premises at one or more of the organizations’ sites, off-premises at a vCloud provider site, or both on- and off-premises.

Analyze a customer use case to determine how cloud computing can satisfy customer requirements.

  • Lets go over some use cases which in turn represents business problems which can be addressed with vCloud services (and a services definition). These use cases are taken from the vCAT Service Defenitions document and further explained here.


    • The Use Case is modernization, a very general use case, but its further explained in the description. The use case is created to address the problem the organization sees with its current IT infrastructure, which is that the business services, processes and legacy applications are not allowing the business to stay competetive. Or in non-IT terms, its taking to to long finish new projects as the focus is wrong and processes are lacking.
    • Risks are the thing that could happen if the use case is not addressed.
    • As you can see a Use Case is really a problem that that can be addressed with  a set of requirements based on cloud computing definitions, and if the problem isn’t address it could have several negative consequences.
      • Make infrastructure more service oriented – defenition of cloud computing.
      • Modernize applications – map what service applications is offering and how it can be packaged into the XaaS model (dependencies etc)
      • Improve speed to market – Automate known/new processes and application deployment into workflows that can be offered as a service to customers.


    • The Use Case is about increasing business capacity and allowing it scale rapidly. So it takes to long to scale compute/storage/network resources to support seasonal or periodic business demand. So when it holiday season everything slows down due to overutilized capacity of resources.
      • Consumers can scale capacity – using the workload mobility defenition. Users can create the workload in other clouds, which have the same security requirements (eg. hosted private cloud – or a hybrid cloud like it’s called)
      • IT can scale up, down, in and out – IT is no longer based on a finite pool of resources but are consumed with 3 distinct models, Pay-as-you-go, Allocated resources with a change of growth, and reserved resources. So business units can scale as they want. And as for the service provider, adding new computer resources are automated as well for quicker capacity growth (Auto deploy, NSX, vSAN, vVOLs etc…)
      • The last two are a similar to the upper two requirements. It’s all about speeding/automating the process of increasing/decreasing resources.


    • The Use Case is about speeding up provisioning of TEST/DEV services. It takes to long for IT to create TEST & DEV environments that are used develop new products and services.
      • Developers and testers can create the environment needed from a predetermined catalog of services to carry out further development of the application or test it in a closed off environment.
      • It’s about automating the provisioning, but IT(or business units) still needs to approve the process to control the usage of capacity. And cost show-back is used to give business units accountability of the usage of resources.


    • The Use Case is based on creating a cloud environment that runs workloads that need to comply to certain security standards. This might include eg. PCI DSS.
      • By using vCenter Configuration Manager whole environments can be tracked for changes and compliancy to many security standards. But please note this use case will require design requirements for both the logical and physical infrastructure.
      • By using vCloud Network and Security, or NSX network isolation can be achieved. If using network isolation with PCI DSS, please refer to the latest PCI DSS documentation on design considerations for virtual environments.

Given a customer use case, determine the appropriate cloud computing model.

  • Please note the following section is bit of simplification on how to determine a correct cloud model for a use case, as this process involves more than just get a couple of requirements and than picking a cloud model. But still a good practice…
  • Cloud computing models include both deployment models (Private, Public, Community, Hybrid clouds) and service models (IaaS, PaaS, SaaS, DaaS, DRaaS and really just XaaS)
    • To define the most used ones the  vCAT Service Definitions document does a good job:
      • Software as a Service (SaaS) – Business-focused services are presented directly to the consumer from a service catalog.
      • Platform as a Service (PaaS) – Technology-focused services are presented for application development and deployment to application developers from a service catalog.
      • Infrastructure as a Service (IaaS) – Infrastructure containers are presented to consumers to provide agility, automation, and delivery of components.
        • IaaS serves as a foundation of additional service offerings, such as PaaS, SaaS and DaaS.
  • If we use the use cases above:
    • Use Case 1: This use case want to modernize their IT infrastructure from a legacy environment to a cloud environment. A private cloud using IaaS would be a good start (and I’m only basing that on the requirements in this single use case).
    • Use Case 2: This use case is to increase business capacity with faster scaling. A private cloud using IaaS would be a good start. Lots of design decision would be based on this requirement though (use of automation of capacity scaling – adding servers, storage, network, and letting customers control their resource usage)
    • Use Case 3: This use case need TEST/DEV environments to be deployed quicker, self-servicing and automated. More information is needed to determine this one, either a private cloud using IaaS, and on top of that you could go for PaaS solution. Or you can use a public cloud,or even hybrid cloud, it all depends on security requirements, data locality requirements or availability requirements just to name a few.
    • Use Case 4: This use case is about making sure the cloud environment comply to certain security standards. A private cloud is a must, and at least a IaaS. But the design would have a lot thing to consider both in the logical or physical design (layout of infrastructure based requirements of security standards etc.)