My VCAP5.5-DCD Exam experience


After a series of reschedules I decided to finally sit a VCAP5.5-DCD exam this week and I passed it. I needed this exam passed to be eligible for VCDX path since I am already a VCAP-DCA since 2014. It was my second attempt after I failed VCAP5.1-DCD back in December 2014 and in this review I will feel tempted to make comparisons between the previous version of this exam and the current one. More on this below.

Exam information

The exam format was exactly as described in the blueprint : overall there were 22 questions from which 7 designs, one master design and remaining 14 being (multiple) drag and drop questions. I was already familiarized with the new format because in March 2016 I sat a beta VCAP6-CMA Design exam which provided an experience that was quasi-identical in form to the one I had this week. The amount of time assigned to me was fair enough to be able to concentrate on each question and make sketches on an exam sheet provided by the test center. It is important to highlight that I am a native English speaker and therefore, I was given an overall amount of 215 minutes.

The format changed radically in comparison to what I experienced back in 2014 and the change is definitely for better. The proportion of design questions against other types of questions is larger than in 5.1 exam format and multiple choice questions disappeared completely. The time management is still an issue but the current exam format is much more manageable than its predecessor.

My approach to pre-exam organisation

VCAP exams are known to be extremely exhaustive to both mind and body. A candidate must take into account the following recommendations if he/she wants to stand a chance and not waste invested money:

  1. Take a long, relaxing sleep the night before you make an attempt. It is really important because an organism deprived of sleep is very likely to turn off attention for long minutes during the exam which is fatal for the final result. It also increases a possibility of keeping nerves intact which is important during the analysis of exam questions.
  2. In the morning on the day of exam take a full meal and drink a considerable amount of liquids. The exam center is likely not to allow you to take a bottle of water with you and during long hours of exam dehydration is very likely to have similar effect to sleep deprivation.
  3. During the exam spent at least 50% of your time on reading questions. Note down first ideas, make sketches if necessary. Do not jump immediately into an answer. Make sure that you clicked on additional notes/details pane in drag and drop questions because these contain information needed to select right choices.
  4. Use next/previous button to jump between questions if you think you do not know how to answer the question immediately. Flag it for future review and continue. Exam takers for 5.1 version did not have such a possibility and they will know what I mean!

My approach to time organisation

Since I knew more less what to expect I decided to take the following time-management strategy during this exam:

  1. Respond to each question in a linear manner with an exception of a master design that I left for the very end.
  2. Spend 45 minutes on the master design question and 10 minutes on each design question, leaving the rest of time on drag and drop questions.
  3. Consider a single visit to the loo. Before the exam starts make sure that you agree with your exam center supervisor about the way to show that you might have to leave the room.

I did not succeed completely with the abovementioned approach because after responding all questions I was only left with 30-ish minutes for the master design question. Therefore, I had to act very fast until the very last second after which I was simply logged off from exam interface. The lesson from this experience is clear: time management is still essential for an exam taker.

My exam experience

Overall, I can say that the new exam format is satisfactory and much better organised than in the 5.1 DCD. It is now definitely putting much more emphasis on design aspects of VMware vSphere infrastructure layer and it does so through a series of very practical excercises. It also presents a complete departure from the style used in previous version where a tremendous pressure was put on an exam taker with around 96 questions to be answered and without a possibility to return after clicking on next question.

The content of certain questions are still completely disconnected from typical project realities but altogether it is now clear that exam creators want to test analytical and abstract thinking instead of checking against simple memorized content. This is why I value VCAP exams so much. I also have to admit that I did not encounter any questions where I had to struggle between my own experience and what someone would call “VMware version of a right answer”. Questions were technologically independent and unbiased wherever it was possible.

The technical content was consistent with the blueprint. Therefore, apart from standard vSphere lab with Enteprise Plus functionalities, deploying resource pools, vApps as a logical container for tiered applications, HA/DRS and vDS is a must. Like many of my predecessors writing similar exam experience posts I definitely recommend to deploy following products which do not enter into a core vSphere suite to gain a practical understanding of their use:

  • Site Recovery Manager for array-replicated DR scenarios
  • Replication Manager for asynchronous replicated DR scenarios
  • Data Protection for backups
  • Enterprise storage appliances to simulate VAAI, VASA and storage policies (I deployed HP VSA and Netapp Ontap Simulator to test these)

I also recommend that in your lab you perform an upgrade of vCenter 5.0/5.1 to 5.5 to have a practical insight into component dependencies and upgrade order. Setting up Auto Deploy and VMware Update Manager for standardised deployments or upgrades of ESXi hypervisor is also a good idea.

I do not agree with those exam takers who expressed their criticism with regards to lack of clarity in certain questions. I definitely did not have that feeling – quite to the contrary, questions were written in plain English and were formed of short sentences which is good. The appearance of terms “like”, “should”, “must” as well as an information about budgetary constraints clearly indicate which are the elements that an exam taker has to concentrate on in the first place. During the entire exam I only identified a single typo which is not a lot in an exam where long texts are dominant.

With regards to technical quality of an exam I can also say that it improved much – visio-style designs seem to work faster and do not freeze the entire exam system after multiple elements are dragged to the design space. This was a particular PITA in previous versions of DCD exam and from what I remember it was also a considerable problem in the beginning of DCD 5.5 exam back in early 2015.

My recommendations for study materials

I know that very few people are likely to attend this exam before its EOL (VMware recently announced EOL for VCAP5-DCV exams) but it looks like the new version is not going to change much with regards to the form. Therefore, traditional study sets mentioned in an excellent Google VCAP-DCD Study Group which are fair enough to prepare of 5.5 version should still be applicable in the future. However, in my review I decided to take a more critical approach to the choice of content used for preparation. I can fully agree with exam participants saying that the amount of documentation and material to learn from is overwhelming. I personally felt that I am going unprepared for this exam because I did not read everything that was recommended by others in a vast VMware community. Therefore, below you will find my subjective opinion about the some of popular study sources :


  • Practice, practice, practice: This is definitely the best recommendation I can give. Obviously, the more you practice through your work, the better. If you have an ongoing VMware project do your best to get involved. Practice designs and know your designs. Take a look at other design proposals in the VCAP-DCD Study Group. Understand component relationship and dependencies and distinguish logical from physical characteristics. Make sure that you understand key service qualities. This is the bare minimum necessary to attend the exam without miserably failing it.
  • : a great site with practical questions and design simulator developed by Jason Grierson. A must-do for anyone who did not attempt this exam in the past and does not know how design or multiple drag and drop questions look like.
  • Pluralsight course developed by Scott Lowe : Designing VMware Infrastructure


  • VCAP5-DCD Official Cert Guide. This book is definitely overhyped and in my opinion it is definitely not worth a price tag it is sold for. There are definitely much better books than this one.
  • VMware vSphere Design – 2nd Edition. In my opinion this book is outdated even for 5.5 DCD exam. Examples and technology decisions given there are not relevant anymore and sometimes introduce a great deal of confusion to a reader familiarised with the current state of VMware technology in 2016.
  • VMware Brownbags: These are great when you are collecting information for your future design in a real world but are not concise enough to provide any extra value during preparation process for this exam. Apart from the fact that the amount of materials shown there is overwhelming and already obsolete (videos date back to 2011), the length of videos was far too great to be able to note down all details. Last but not least: the voice recording quality is very poor and really annoying for more senstive ears.

Somewhat irrelevant:

  • Mastering VMware vSphere 5.5 : This book intends to satisfy all kinds of needs from the most basic information for an administrator starting his/her career in VMware technology to an IT Architect working on infrastructure migrations. Its structure does not respond to the exam blueprint and does not go through principles tested on an exam, such as service qualites or design characteristics (requirements, constraints, risks etc.). It is a great reference for best practices and validated configurations but these can be read for free in an official VMware documentation.


This exam definitely helped me to keep a focus on collecting information, best practices and recommendations for a real-life design I am currently working on. Vice versa, my practice at work allowed me to prepare better for this exam as well. I think the good side of VCAP-DCD experience is a complete familiarity with a basic IT architecture design of VMware products in the field of Infrastructure-as-a-Service. Combined together with other industry standards such as Open Group or internal design methodologies it serves well to create comprehensive design documentation for the real project but also help in creation of re-usable artifacts intelligible to other owners of VCAP-DCD certificate.

With two VCAP exams in my pocket I have doors opened for VCDX. Before considering this opportunity I will probably prepare for VCAP6-DCD immediately after it becomes GA.

Post scriptum

VMware finally managed to somehow convince PearsonVue to allow attending this exam in more test centers. This is definitely a good step forward. Back in 2014 I booked my VCAP exam in the only test center in my country knowing that it will be closing doors to VCAP exams from 2015 onwards.

In my opinion the price tag for this exam is set very high. VMware should consider providing candidates with discount vouchers, release them more often than once a year during VMworld event and set a more considerable discount level.


overrideIcaClientName variable and Firebird database-backed applications issues on Citrix Xenapp

Together with my client I recently encountered a very interesting problem whereby one of their homebrew applications recently ported to Citrix Xenapp did not function correctly. Basically it was showing a (rather misleading) error message which indicated that there might be a connectivity problem between the frontend (installed on Citrix SBC hosts) and the backend (based on firebird database).

Initially we thought it might be related to the fact that it was wrapped into App-V 5 package but that was immediately excluded when it was found that in a separate environment the package was actually launching without any problems. I then went through the usual analysis starting from policies comparison and ending with a long night spend on comparing procmon logs to search for more in-depth clues. Although I found that the frontend was able to initialize the connection, a quick comparison with a normally working version made clear that a standard sequence was not completed.

Thanks to my client who had an access to the backend it was possible to detect that something is going wrong with a connection process to the firebird database. Basically, an application was written in a way to register the user from which a frontend connection was coming from (here: a host from which ICA session was initialized). It was doing it through inserting the hostname and adding an additional random string to uniquely identify the connection. What was really boggling our minds was that instead of a standard hostname a random string was presented. That random string was also particularly long. As a result, together with an added part, that string was longer than 31 characters which was more than firebird database was capable of accepting.

With that in mind I again compared a working environment’s configuration, this time centering my attention on policies part (Citrix policies, GPO policies) but found nothing interesting. A little research on the internet suggested that the client name variable was being manipulated by Citrix Web Interface instead of Citrix policies. Basically, it was possible to override client name with a random string to obfuscate the origin of the ICA connection or generate a new name with each new connection by editing Web Interface / Storefront configuration. The variable in question is called overrideIcaClientName and it should be set to OFF in order to fix the variable and show the real host name (which usually is much shorter than 32 characters!). After changing that string the frontend application started to work like a charm as a standard application as well as an App-V package.

Although it might be considered as a purely engineering task, I also found this story challenging from solution architecture perspective. Porting an application to the new Citrix environment was an important milestone in a project I am currently working on. It was impacting for all sides and a search for a solution required active participation of several parties with a different background. Searching for possible culprits and usual suspects (Microsoft App-V, Citrix, Windows OS, GPOs, human errors) took a considerable amount of time and human resources. My personal note to this is that a Citrix Administrator not only has to have a holistic overview of all associate services around a product he or she is responsible for but  also has to be able to speak with AD administrators, application developers and (obviously), the client. Without a thorough application analysis from the backend (to which usually Citrix Admins do not have or do not want to have access) it would not be possible to find out a solution.

Another point is that Citrix shot itself in a foot by barring this unfortunate variable “client name” from the Citrix Studio management console in Xenapp 7.x. In comparison to previous versions of Xenapp it is barely visible in the GUI (you only see it when you actually click on a connection in details pane. But it’s so frustrating to search for this information because refreshing Citrix Studio is horribly slow!); Instead of it, a much faster way is to use a powershell cmdlet that links the troubled user name with his/her clientname variable:

get-brokersession | select username,clientname

For more details about how to edit overrideIcaClientName, please click here for Web Interface and here for Storefront. After editing the .conf file it may be necessary to reboot the server altogether because a simple iisreset did not work for me. If you want to understand use cases for changing this variable I suggest that you read this article.

open-vm-tools tcz extension for TinyCore 6.4

For those who would like to install open-vm-tools on the newest TinyCore release, please find enclosed below a link to a compiled .tcz extension. It is still necessary to download some dependencies which are listed in build-dependencies. In my particular case for open-vm-tools to install and run on Core 6.4 it was necessary to download following extensions:

  • squashfs-tools

To learn how to build and install a TC-based VM with open-vm-tools on board, feel free to visit this link.

How to build your own yVM: step-by-step process

The following instructions were tested on VMware Player, standalone ESXi and clustered vSphere 6.0.


  1. Download Core 5.4
  2. Create a new VM with following characteristics:
  • 1vCPU
  • 64MB HDD (IDE0:0)
  • 64MB RAM (in the end you will switch it to 48MB but you may need more for the installation process)
  • Remove unnecessary peripherals such as floppy drive etc.

Core Installation

Once the boot process is completed, the first step is to install TinyCore on a hard drive. Run following commands to install binaries that you will need in later process:

$ tce-load -wi cfdisk.tcz grub-0.97-splash.tcz

$ sudo su

Check which drive is representing your IDE vmdk file. By default it should be /dev/sda or /dev/sda1 :

fdisk -l

Open cfdisk in order to create necessary persistent partitions :

$ cfdisk /dev/sda1 (sda stands for your VMDK file)

In cfdisk, create two partitions:

  • 1 x 32MB bootable partition and
  • 1 x Swap partition (code 82 for type of partition)

Note: After creating partitions do not forget about committing changes and setting the EXT partition as bootable!

exit cfdisk

rebuild the filesystem information:

$ rebuildfstab

Create an ext3 filesystem :
$ mkfs.ext3 /dev/sda1

(mount your newly created Linux partition and ISO file)
$ mount /mnt/sda1

$ mount /mnt/sr0

Create necessary folders where grub and boot files will be copied to:
$ mkdir -p /mnt/sda1/boot/grub

$ mkdir -p /mnt/sda1/tce

Copy boot and installation files :

$ cp -p /mnt/sr0/boot/* /mnt/sda1/boot/

$ touch /mnt/sda1/tce/mydata.tgz
$ cp -p /usr/lib/grub/i386-pc/* /mnt/sda1/boot/grub/

Create e a new grub menu list

$ vi /mnt/sda1/boot/grub/menu.lst

press “i” key to enter edit mode. then include the following information:

default 0
timeout 0
title <yourVMtitle>
kernel /boot/vmlinuz quiet
initrd /boot/core.gz

type “:wq” to exit and save changes.

Open Grub setup:
$ grub
In the grub prompt, type

$ root (hd0,0)
$ setup (hd0)
$ quit

type umount /mnt/sr0, then eject /dev/sr0
type reboot

Note: Make sure that ISO file is unmounted from your VM to avoid a boot from it during the restart.

Software installation

After the reboot you should end up in a bash shell. Continue with the installation of openssh, nano, nginx and open-vm-tools.

Let’s start with openssh:

$ tce-load -iw openssh
$ cd /usr/local/etc/ssh
$ sudo cp ssh_config.example ssh_config and then sudo cp sshd_config.example sshd_config
$ sudo /usr/local/etc/init.d/openssh start
$ passwd (and change password for user tc)
$ sudo passwd (and change password for user root)

From now on you may continue the installation process via an ssh session but beware, this is not the end! Do not reboot your VM yet.

Install nano:

$ tce-load -iw nano

Install nginx:

$ tce-load -iw nginx

Install open-vm-tools:

Download open-vm-tools binary and dependencies from here.

Unpack them and upload them via scp (or winscp if you use Windows OS):

$ scp /<unpacked_packages>/* tc@<yVM_ip_address>:/tmp

Install packages in the following order:

tce-load -i openssl.tcz openssl-dev.tcz  libdnet.tcz  open-vm-tools-modules-3.8.13-tinycore.tcz libtirpc glib2 fuse open-vm-tools

Check if all aforementioned packages are present in /mnt/sda1/tce/optional/

If not, copy missing tcz’s :

sudo cp /tmp/name_of_the_package.tcz /mnt/sda1/tce/optional/

Now save all your work before performing a reboot:

$ sudo nano /opt/.filetool.lst


$ sudo nano/opt/

# put other system startup commands here
/usr/local/etc/init.d/openssh start
/usr/local/etc/init.d/nginx start

$ sudo nano /mnt/sda1/tce/onboot.lst


verify that open-vm-tools is up and running:

$ sudo /usr/local/etc/init.d/open-vm-tools start

Eventually, save all configuration with the following command:

$ sudo -b

You may now shut down your VM, change the amount of necessary RAM to 48MB and reboot it again.

yVM: Download Page

yVM is a very small VM based on TinyCore 5.4 (kernel 3.8.13) and has open-vm-tools, nano, openssh and nginx installed. You can read a story about the the project here. If you want to know how to build your own yVM, please click here.

The current version has following characteristics:

  1. 1vCPU,
  2. 48MB RAM,
  3. 64MB HDD, divided into two partitions:
    1. one 32MB /dev/sda1 ext3-formatted partition
    2. one 32MB /dev/sda5 swap partition
  4. open-vm-tools installed as per instructions from Lapawa + some manual tweaking;
  5. openssh, nano and basic nginx installation (http only).
  6. available usernames: tc and root
  7. password for both accounts: VMware1!

vSphere-compatible OVA: download (Redirection to Google Drive, MD5 checksum: cff70e1fdcc4ef3307ff364e2f93c775).

yVM: An ultra small VM with VM tools

Home labs used to test virtualization solutions are very often limited by physical resources which either require to size down test environments or to accept a general slowness. This is particularly painful with pseudo-converged infrastructures or nested ESXi’s. Regarding the latter, my opinion is that it has a great drawback with the use of storage at 1/10 of available IOPS in comparison to a VM installed directly on a physical ESXi host.

This frequently results in a situation where a simple operation on a VM such as deployment from a template or via vRealize Automation, a DR test of a Protection Group with Site Recovery Manager or simple SDRS operations were taking dozens of minutes, thus blocking other operations on a nested cluster.

Since I was under pressure to provide some documentation for a project, I promised myself that in a free time I will look for a solution to tackle the issue I described above. More recently, I decided to look for small Linux distros that would fulfil the following conditions:

  1. be very small in size (in my particular case the IOPS was the limit)
  2. use a small amount of physical memory
  3. have VMware Tools or equivalent enabled

Initially, I found that there is no perfect solution to satisfy all of the aforementioned requirements. As a workaround I decided to make a lightweight VM myself only to land with an Ubuntu 14.04 with open-vm-tools, 192MB RAM and 5GB HDD (slimmed down to 2GB thanks to thin-provisioning). That was kind of a progress but was still fairly big in terms of storage.

Fortunately, many homelab and virtualization blogs mentioned Tinycore (here, here, here, here). VMware communities also provided a richness of information about this distro (here, here, here). Personally, until now I used to have some rather unsuccessful experience with TC but I decided to give it a chance (again). TC is a very interesting case of a lightweight Linux distro designed to run pretty fast even on a very old hardware. Alternatively, it is used for appliances due to its architecture which implemented busybox to make OS non-persistent across reboots.

I dig deeper in order to determine if it would be a right choice, especially with regards to Tools installation. The problem is that although creating a VM and making configuration persistent wasn’t much of a fuss, getting VMware tools working on top of it was a completely different story. My plan was to build a VM that would satisfy following scenarios:

a) Have a smallest footprint possible with regards to RAM and HDD

b) Have VMware Tools or Open VM Tools (which are officially recognized by VMware as an equivalent of VMware Tools) installed

c) Provide very basic services such as SSH server and HTTP server (in order to play around connectivity scenarios such as NSX or SRM)

A rather logical decision was to use the most up to date release of TinyCore 6.4 (based on Linux kernel 3.16) but after around 10 different iterations I landed with a VM that required around 116MB of RAM to be turned on successfully. Moreover, the stability was not perfect because sometimes during the boot process there was no memory left which forced TC to start killing off processes in order to avoid a kernel panic (which it eventually did anyway).

I was not discouraged by this and instead of using the newest distro I went back to earlier releases 3.x, 4.x and 5.x. I decided to install it from scratch through the cli via a core ISO (9MB in size) to make sure that only essential services are installed. If you want to know the step-by-step procedure to do it on your own, click here. I compiled open-vm-tools version 9.10 on a separate VM with an identical distro to leave all the rubbish behind and just obtain a clean .tcz extension with dependencies.

Eventually, I found that an initial concept developed itself into a small project which resulted with an extensively tweaked distro. I called it yVM, whereby the prefix is borrowed from -yocto measure base to highlight its small size. It is based on TinyCore 5.4 (kernel 3.8.13) and has the following characteristics:

  1. 1vCPU,
  2. 48MB RAM,
  3. 64MB HDD, divided into two partitions:
    1. one 32MB /dev/sda1 ext3-formatted partition
    2. one 32MB /dev/sda5 swap partition
  4. open-vm-tools installed as per instructions from Lapawa + some manual tweaking;
  5. openssh, nano and basic nginx installation (http only);
  6. available usernames: tc and root;
  7. password for both accounts: VMware1!.

Some remarks about the above release:

  1. The interface is CLI-only. I consider it to be destined purely for testing purposes in VMware-based environment without much interaction with the the OS itself (apart from connectivity tests i.e. ssh and http);
  2. I removed all unnecessary peripherals such as floppy drive etc.;
  3. In order to maintain backward compatibility with previous VMware vSphere environments, the vmx-hardware level is set to 8 (which is vSphere 5.0 compatible).

All in all, the VM has a size of 19MB when thin-provisioned, it still retains around 6MB of free RAM and 12MB of free HDD. The IP is obtained dynamically through DHCP, however that can be changed if necessary. It was tested succesfully in following scenarios:

  • Graceful shutdown, SDRS, vMotion and HA on vSphere 6.0;
  • Protection Group test, failover and failback with SRM 5.8;
  • VXLAN overlay and layer-2/3 connectivity via Edge Gateway with NSX 6.2;
  • Replication with VRM 5.8.

Soon I am planning to test it against VMware FT, as well as vROPs and VeeamONE. In my spare time I will also pre-package it into an OpenStack- and Docker-compatible image.

If you are interested in trying it out, feel free to download an OVA file by clicking here. (Redirection to Google Drive, MD5 checksum: cff70e1fdcc4ef3307ff364e2f93c775).

If you want to build your own small VM, plase read this post.