Remote VCAP-DCV Deploy exam experience

Hi everyone! On September 4th I took the VCAP-DCV Deploy 2022 exam and passed it so this post will be focused on my experience of taking it remotely through Pearson Vue platform.

Long time ago, I wrote a post about preparing for a VMware exam and a couple of things have changed since January 2021 related to deploy exams.

First and foremost, by the time I wrote that post, deploy exams were not allowed to be taken remotely but now they are. The process of scheduling it is exactly the same as for any other exam so nothing change on that side.

To give more detail to the ones that don’t know how a VCAP Deploy exam is, you are given some questions (the amount depend on the exam) with multiples tasks to do (e.g.: create a cluster and then configure HA, DRS, DRS rules, syslog, etc.). The type of questions will be related to the blueprint of the exam (read the post mentioned earlier to understand where to get the blueprints). The environment you are given is exactly as a HOL Labs experience (when taking it on site) with the difference that is exam is embedded into the Pearson Vue app (when taking it remotely). On each sides you will have a console and a manual tab that can be pined or floating to allow resizing. You are allowed to have 1 screen only so having a higher resolution would be you best ally for this type of exams.

Regarding the exam itself, the overall experience was really good. I was using QHD resolution and the exam environment adapted automatically to my resolution (Note: don’t know if this is always done automatically as I only took this exam remotely by the time of writing). This was extremely important during the exam because there was no need to spend time adjusting the browser zoom.

Some recommendations about the exam:

  • Pay attention to the instructions given, if it says not to reboot the host, DO NOT REBOOT IT. Read the complete instructions first and then go into what you are being requested.
  • Don’t wait for tasks to end if it’s going to take long, for example: rebooting a virtual machine, send the reboot action and come back later.
  • If you have some buttons on the either side and they are hidden because of the manual and/or consoles panel, pin it to the other side and keep going with the exam. Don’t lose time trying to zoom in/out the browser to make that button appear, it might never happen if it to close to the edge of the screen.
  • If you don’t know how to do a question, skip it and come back later when finished with the ones that you know, time management is very important.
  • Use notepad to make some notes about tasks that you have to finish yet if your memory is not good enough.
  • Avoid using the console tab unless you are sure that you need them, it takes time to change between them and you might lose some valuable time there, especially if you are doubting which one you need and clicking between multiple of them. Try to access that resource through the network first and if you can’t then go to the console tab.
  • Be confident on how to use VMware documentation and KB’s, some resources are being given to you to help but you should know where to look for the steps.

They exam environment had some struggling parts too. When I started to use keyboard shortcuts my right click “got stuck”, not physically, but digitally. I was not able to click between tabs or access any other shortcut on the desktop or taskbar. What saved me was to know a couple more keyboard shortcuts to bypass that click restriction in some areas, using ALT+TAB to reach the desktop and then hit the first character of the shortcut that I was trying to access (e.g.: putty), so my recommendation is to be confident with this too before taking the exam. I temporary fixed it going back and forth between consoles, but it got stuck again later on.

Going into the results, they are not shown automatically like any other exam (VCP or VCAP Design). It takes between 24-48 hours to arrive. Mine took less than 24 hours, including the VMware certification and badges (VCAP and VCIX) so great timing.

Example of the email you will receive about the outcome of the exam

That is the end of the post, if you like it, be sociable share it!

VMware Cloud Director Upgrade History

Hi everyone and welcome to a very short post. This post is going to cover something that I was asked today. The question I have received was “Do you know the upgrade history of our VMware Cloud Director enviroment?”

You can find the upgrade steps in the following link

Note: The following steps apply only for the appliance deployment.

To troubleshoot the upgrade, there is a file you can check to monitor the upgrade process.


In the file you can find the following information that shows from which version you are upgrading and the destination version.

Said that, I have created a single liner

more /opt/vmware/var/log/vami/updatecli.log | grep "to version"

The result of that one liner is the complete upgrade history. Keep in mind that if you delete this file or you redeploy a cell for any reason, that information won’t be available.

I hope you enjoyed this rush post.

If your are interested in a specific topic, let me know in the comments section below and I’ll be happy to write a new post about it.

Be sociable, share it!

Troubleshooting VMare Cloud Director Log Bundle generation

I know it’s been a while since my last post, so I’m very happy to be again on the road.

Last week I had some issues in a VMware Cloud Director enviroment that ended up opening a support request with VMware. During the case development, the support team requested me to create a log bundle, but I wasn’t even able to generate it, so that’s where this story begins. Please note that the modifications I’ve done might not be supported by VMware.

For those who are not familiar on how to generate a VCD log bundle, here are the steps

The error that I was having was the following

General message showing the general error message
Some Cells where showing a FAIL status. In this image just one but most of them where showing the same status

The first step to troubleshoot this situation was to identify which cells were the ones with a FAIL status. The CELLID can be obtained with the following command

 more /opt/vmware/vcloud-director/etc/ | grep cell.uuid

To troubleshoot the bundle generation process there are two log files located under /opt/vmware/vcloud-director/logs


This first log file shows if the cell detects the marker file that indicates the cell to start generating a lod bundle. On a regular situation it should look like the following

This means that the cell has detected a marker file
This is the marker file located in

From that side everything was looking perfect, so I went into the other file to understand what was happening.

Normal log file situation. Started and completed

Analyzing the logs I found two different errors. The first one, that a log collection process was still running. The way I managed to fix this, was to shutdown the cell services and start them again.

Abnormal situation, a log collection process was still running

The second error was just a timeout. I wondered where that timeout could be configured to extend it.

Abnoral situation. Timeout reached and marker has been removed

After I realized about that, I started digging deeper into the support bundle generation script.


I’m not going to cover the complete script because it’s not the central topic of the post. In that file I found the some variables that pointed me into the multi-cell-log collection script, so it was time to check that file also.

vmware-vcd-support script variables

I opened the file with the following command and founded that there was a timeout variable that I could modify.

 vi ${VCLOUD_HOME}/bin/vmware-vcd-multi-cell-log-collector
Timeout variable without modifications

So I decided to modify that value and try again. It’s not a value that will wait until it expires, it’s just a maximum timeout. If the cell bundle generation ends earlier, the script will continue.

Modified timeout value

After modifying that timeout everything was working again so I returned to the vmware-vcd-log-publisher.log to analyze how much time was taking, just out of curiosity. It was taking between 8-9 minutes, a little more than the default.

I ended up doing a cleanup of old logs, and the process was smooth again in less than 7 minutes.

There is another reason why this process might fail and its detailed on this kb

If your are interested in a specific topic, let me know in the comments section below and I’ll be happy to write a new post about it.

Be sociable, share it!