31 March 2022

ESXi Access to resource settings on the host is restricted

I was trying to upload an ova file thru vCenter when I got an error message about a controller type in this particular ova. From prior troubleshooting, I knew that the workaround was to just log directly onto a host and upload the ova directly to the host. I know I had done this before so I was confused for a brief moment when I got the error message:

Access to resource settings on the host is restricted to the server that is managing it: xx.xx.xx.xx.

Okay… so the ESXi host is being managed by vCenter. How do I finagle my upload onto a host? Here’s how…

  • Enable SSH (if it is disabled) on the ESXi host you want to upload/deploy your ova or ovf to.
    • You should know how/where to enable SSH… If you don’t there are plenty of articles you can google.
  • Connect to the host via SSH.
  • We want to stop the service that allows the ESXi host and the vCenter to communicate. To do so we want to run the following commands.

/etc/init.d/vpxa stop
/etc/init.d/hostd restart

  • Deploy your ova or ovf to your host thru the ESXi host’s DCUI WebGUI.
  • After you deploy your virtual machine, restart the VPXA service via SSH on the ESXi host.

/etc/init.d/vpxa start

  • Wait a couple of minutes while the ESXi host and your vCenter re-establish communication between each other.
  • If SSH was previously disabled, re-disable it on your host.
2 February 2022

vMotion Greyed Out

Okay… This was a first for me. I was in VCSA and went to vMotion a VM, a totally normal task. However, upon clicking on the VM and trying to run the vMotion, it option was greyed out. WHAT THE HECK!?!
Well, thankfully it ended up being a simple fix. Apparently, this can happen if the VCSA database does not get properly updated after a backup job. Here’s how to re-enable it.

Manually remove entries from the vCenter Mob:

  1. Identify the VM’s MOB ID
    1. Open a web browser and go to the vCenter vSphere Client (HTML5)
    2. In the left hand side inventory, select the affected VM’s object
    3. With the VM selected and highlighted, in the URL bar, review the string and look for “VirtualMachine:vm-xx

Example: https://<VCSA-FQDN>/ui/#?extensionId=vsphere.core.vm.summary&objectId=urn:vmomi:VirtualMachine:vm-69:7071ab73-c123-4d56-ef78-1234gh56i7jk&navigator=vsphere.core.viTree.hostsAndClustersView

In this example VM’s MOB ID is vm-69.

  1. ​​​​​​Access the Virtual Machine Operations by opening a web browser to: 

https://<VCSA-FQDN>/mob/?moid=AuthorizationManager&method=enableMethods

  1. Login with administrator@yourssodomain.local or an SSO admin user (administrator@vsphere.local)
  2. The below page will appear:
  1. In the first parameter entity value box, replace MOID with the VM’s MOB ID

<!– array start –>
<entity type=”ManagedEntity” xsi:type=”ManagedObjectReference”>vm-69</entity>
<!– array end –>

  1. In the second parameter entity value box, enter this command:

<method>RelocateVM_Task</method>

  1. Click on “Invoke Method” in the lower right corner.
  1. Refresh the vCenter Server web client and the migration option for the VM should now be available. If the issue persists, try restarting all of the vCenter Server services.

Here is VMware’s KB about it.

28 January 2022

Nutanix LCM – Insufficient space on ESXi scratch disk

I was running into an issue where I could not run the Nutanix LCM Inventory action on a cluster because the scratch disk on an ESXi host was too small. And it seems reasonable to assume that if you’re reading this article, then you too probably have encountered an with the pre-check “test_esxi_scratch_space“.

I’ve seen the issue a few times now, and in my experience, the ESXi host has always just had its scratch disk set to the wrong disk. The first couple of times I saw this, the fix was to update the scratch disk from within the advanced host settings in VCSA. The part I did not like about fixing the issue this way, was that it required a reboot of the host for the setting to take hold. Having to schedule a maintenance period or create downtime is never an ideal solution. Thankfully I learned that there is another way to repoint the scratch disk that requires no downtime and it only requires a few lines of CLI against the ‘problem’ ESXi host.

Start by connecting via SSH to the ESXi host that is having the issue with the scratch disk.

Run the command “ls -ll /scratch” to find which volume is currently set as the scratch disk

root@ESXi# ls -ll /scratch
lrwxrwxrwx    1 root     root            49 May  8 23:40 /scratch -> /vmfs/volumes/5xyzxyz6-dxyzxyzb-1c73-ac1xyzxyz990

Run the “df -h” command to list all of the disks on the host and their sizes

root@ESXi# df -h

Filesystem   Size   Used Available Use% Mounted on
NFS          1.6T   1.4T    127.4G  92% /vmfs/volumes/OS-XXX-Repoxxx
VMFS-5      52.0G   1.1G     50.9G   2% /vmfs/volumes/NTNX-local-ds-17xyzz340111-B
vfat         4.0G  27.6M      4.0G   1% /vmfs/volumes/5xyzxyz-1234xyzz-12xy-1234xyzz1234
vfat       285.8M 205.8M     80.0M  72% /vmfs/volumes/5xyzxyz6-dxyzxyzb-1c73-ac1xyzxyz990
vfat       249.7M 152.6M     97.2M  61% /vmfs/volumes/58xyzxyz-cdxyzxyz-766a-12xyzxyz1226
vfat       249.7M 145.3M    104.4M  58% /vmfs/volumes/b4xyzxyz-80xyzxyz-9bf2-e5xyzxyzf6d0

Now that we have the current scratch disk and a list of the sizes of all the disks, we can check if the scratch volume is indeed set to the volume that is 4GB in size.

In the example above we can see that the volume “/vmfs/volumes/5xyzxyz6-dxyzxyzb-1c73-ac1xyzxyz990” is only 285MB in size. That means that this current volume is far too small. No wonder we’re getting an error.

We want to set our scratch disk to a volume that is 4GB in size. According to the list above that means we want to use the volume “/vmfs/volumes/5xyzxyz-1234xyzz-12xy-1234xyzz1234”. To set the desired scratch disk we’ll use the command “ln -sfn <volume_id> /scratch”.

root@ESXi# ln -sfn /vmfs/volumes/5xyzxyz-1234xyzz-12xy-1234xyzz1234 /scratch

If we recheck what the scratch disk is on our host, we’ll see that it is now set to the proper disk volume.

root@ESXi# ls -ll /scratch

lrwxrwxrwx    1 root     root            49 May  8 23:40 /scratch -> /vmfs/volumes/5xyzxyz-1234xyzz-12xy-1234xyzz1234

Now that the scratch disk is properly configured on the host we can update it in VCSA and be done.

From the Host, go to Configure, then Advanced Systems Settings, and click “Edit”.
Select “ScratchConfig.CurrentScratchLocation” and set it to the same value that you just manually configured on host. Hit “Apply”, and you’ll see that the VCSA now recognizes the newly configured scratch disk.

Well now we’re done, and we didn’t even need to reboot a single physical host! You can read more about this error in Nutanix’s KB article about it.

1 January 2021

VMware PVSCSI on a new Windows install

If you haven’t already upgraded your Windows servers to Windows 2019, then you will probably be doing so soon enough. That means that it’s time to review the steps you take in building out your virtual machines (VMs). Are you running your VMs from a SAN? Then during this refresh, you should really take the time to consider using the VMware Paravirtual SCSI (PVSCSI) driver.

VMware Paravirtual (PVSCSI) adapters are high-performance storage adapters that can provide greater throughput and lower CPU utilization. They are best suited for environments where hardware or applications drive a very high amount of I/O throughput, such as SAN environments. PVSCSI adapters are not suited for DAS environments.

VMware, https://kb.vmware.com/s/article/1010398

When building new VMs there are four options you can choose from for their SCSI controller. The default LSI Logic SAS driver that is automatically selected for you will work just fine in most environments. That said, when you want to guarantee maximum performance from your VMs you will need to use the PVSCSI. Why wouldn’t you want to allow your VMs their max performance? It’s simple enough to do. Heck, do it and make a “golden image” template so you can easily redeploy it if you don’t want to repeat the steps on each VM everytime. It’s just a couple of clicks now for better performance later. Here we go…

  1. Launch the vSphere Client and log in to an ESXi host or vCenter Server.
  2. Select create a new virtual machine.
  3. In the vSphere Client, right-click on the virtual machine and click Edit Settings.
  4. Click the Hardware tab.
  5. Click Add.
  6. Select Hard Disk.
  7. Click Next.
  8. Choose any one of the available options.
  9. Click Next.
  10. Specify the options you require. Options vary depending on which type of disk you chose.
  11. Choose a Virtual Device Node and specify whether you want to use Independent mode. For data disks, choose a Virtual Device Node between SCSI (1:0)to SCSI (3:15). For a boot disk, choose Virtual Device Node SCSI (0:0) or choose the Virtual Device Node that boots in the order you require.

    Note: To set a disk to use Independent mode there must be no snapshots associated to the virtual disk, if there are existing snapshots commit them before changing the disk type.
     
  12. Click Next.
  13. Click Finish to complete the process and exit the Add Hardware wizard. A new disk and controller are created.
  14. Select the newly created controller and click Change Type.
  15. Click VMware Paravirtual and click OK.
  16. Click OK to exit the Virtual Machine Properties dialog.
  17. Power on the virtual machine.
  18. Install VMware Tools. VMware Tools includes the PVSCSI driver.
  19. If it is a new virtual disk, scan and format the hard disk within the guest operating system.
26 March 2020

Howto: Folding@Home – VMware Fling


VMware is doing their part to help make it easy for folks to contribute to the Folding@Home (F@H) project. They have packaged together an appliance as an OVA file on VMware Flings that you can deploy on any of their virtualization products either on your hardware or in a cloud, using Workstation or Fusion, or ESXi hosts. That means that with just a few clicks you can download and deploy a VM running on the super light-weight PhotonOS that has the F@H client pre-installed and is ready-to-go.

You might be asking why this is so great, I mean the client isn’t exactly difficult to setup on other operating systems. Well you are correct. This fling is geared towards VMware virtualization enthusiasts and professionals that already have homelabs or datacenters, with idle compute power they want to contribute. By using those idle resources and dedicating an VM appliance towards contributing, it basically becomes a set-it-and-forget-it deal that will always be chugging along in the background.

If you are new to virtualization, then deploying this appliance can serve as a great way to learn about flings, appliances, and deploying a VM in general while contributing to a cause.

Note: If you intent to deploy this in your company’s data center, or your work pc/laptop, you should make sure to have permission to allow for it from the appropriate people in your organization before deploying, just to cover your ass.

Step 1: Create your Passkey

If you don’t already have a username and passkey, then the first thing you’ll need to do is create your user and get your passkey. You’ll use this later as you deploy the appliance. If you already have yours, then proceed to the next step.

https://apps.foldingathome.org/getpasskey

Just to let you know, when I signed up earlier this week, it took a few hours for me to receive my passkey from F@H. So don’t get upset if you don’t hear from them immediately after clicking “Get Passkey”.

Step 2: Download the Fling

The first thing we need to do is download the OVA from the WMware Flings website.
https://flings.vmware.com/vmware-appliance-for-folding-home

Step 3: Deploy

Workstation

1. Double-click on the OVA file you download to launch VMware Workstation. It will present you a wizard to “Import Virtual Machine”.
Enter a name and file path for your F@H appliance, then click ‘Next’.

2. Now to work down the options from the left pane…

-Enter a hostname
-Enter an IP address (leave blank if DHCP)
-Gateway
-DNS

-Enter password for the appliance; VMware1!
*This is the root password for the appliance

-Enter you F@H username
-Enter your F@H team (Leave as 52737 to contribute as part of VMware’s team)
-Enter your Passkey
-GPU (If using a GPU change to TRUE, if you are using a virtual machine with a GPU, this must be in passthrough mode)
-Enter F@H management networks info (can probably leave alone)
-F@H password defaults to the OS password (VMware1!)

Then click ‘Import’.

Go ahead and use my F@H username & passkey if you really want to fold as me… It just means my F@H user will get credit for any folding you do.

3. Once the import is complete, it should automatically power on. Go ahead and power it off. The first thing I recommend to do is upgrade the VM.

Click on “Upgrade this virtual machine” and follow the wizard to upgrade it to the highest version that is compatible in your environment. For me, it is Workstation 14.x.

Because this is an OVA file and so easy to re-deploy if I screw something up, I choose to just alter the VM, and not make a clone.

4. Next step is to edit the VM and add more CPUs, if desired. Click on “Edit virtual machine settings”.

Click on ‘Processors’. From the “Number of processors” dropdown you can choose how many processors you want to dedicate to this appliance. Then click ‘Ok’.

5. Go ahead and power on your F@H appliance.

ESXi / vCenter

1. In vCenter or on your ESXi host, right click on your Datacenter/Cluster/Host and select “Deploy OVF Template”.

2. Select the OVA file you downloaded earlier, and click ‘Next’.

3. Give your VM appliance a name, and click ‘Next’.

4. Walk thru the rest of the wizard. Choose your computer resource you wish to deploy it on to. Review the details. Select your storage. Select your network.

5. Customize the F@H template setting for your environment.
-Hostname
-IP address
-Gateway
-DNS
-OS ‘root’ password
-F@H username
-F@H passkey
-GPU
-F@H remote management password

Then click ‘Next’ and ‘Finish’ to deploy your new appliance.

6. Once deployed, make sure the vm is powered off. Right click on the vm and select ‘Edit Settings…”. Select CPU and from the dropdown adjust the CPU to the desired number you wish to dedicate to your appliance, and click ‘Ok’.

7. Power on your F@H vm and you are ready to start contributing.

Step 4: Troubleshooting

Once your appliance is up and running, there are a few command that you will find helpful.

Start and Stop
/etc/init.d/FAHClient start
/etc/init.d/FAHClient stop

Restart
/etc/init.d/FAHClient restart
Status
/etc/init.d/FAHClient status
Check the Logs
/etc/init.d/FAHClient log -v
Check CPU stats
top

With the huge growth of contributors to F@H, it has made getting work units more difficult. If you check your logs and see messages similar the what is in my screenshot below, then your appliance IS working, it is just waiting for work.

Leave it running and you’ll eventually see it start chugging along when it gets a work unit.

Also, on the F@H fling website you can also find two PDFs, one about deployment and another with FAQs. Give those a look if you run into any other issues.

25 March 2020

PhotonOS – Set timezone

PhotonOS is VMware’s minimalist Linux based OS that has been heavily optimized for vSphere environments. Many of VMware’s appliance and OVAs are based on this super light weight platform. The problem with appliances and OVAs, is that I have yet to find or launch one that is set to MY timezone by default. I guess that is the price I have to pay for living in Hawaii.

While having the timezone mis-configured probably won’t hurt the VM itself most of the time, it definitely makes reading timestamps and logs more difficult. I mean come on, we’ve all been there before, add or subtracting your timezone offset to figure out what time an event actually happened since we probably don’t live in the GMT or UTC timezones. Much to our luck, setting the timezone PhotonOS using SSH (or the console’s CLI) is pretty easy after you log in as ‘root’.

Enter the command below to get a list of all available timezones.

ls -lsa /usr/share/zoneinfo | more

If you live in a region that is divided into subregions, such as the ‘Pacific’, we can use the following command instead to list those zones.

ls -lsa /usr/share/zoneinfo/Pacific | more

Once you have found the name of your desired timezone you can use the following command to set it. I’m using “Pacific/Honolulu” as my desired timezone.

set Pacific/Honolulu timezone

Then make a symbolic link from localtime to “Pacific/Honolulu”, or your desired timezone…

ln -sf /usr/share/zoneinfo/Pacific/Honolulu /etc/localtime

The final step is to check and visually confirm that the timezone is correct. To do this, we simply run the following command.

date

Now we can finally make some sense out of our logs!!!

19 March 2020

CUCM 10.5 – Updating VMtools

Cisco Call Manager is an integral part of any company that runs it for all of their “voice” or telephony services. I’ll be honest… I’m always a little afraid to console in and do stuff on a CUCM server because I don’t feel like I know enough to quickly troubleshoot issues I might cause.

However that doesn’t mean that I can avoid CUCM all together. I do have to jump into a CUCM server occasionally. Like when it’s been virtualized and it’s time to update the version of VMware Tools (VMTools) that is running on it. Thankfully, that task is a lot easier than it might initially seem. I’ll demonstrate how to upgrade the VMTools on a server running CUCM v10.5.2.

In vCenter, select your CUCM server. Dropdown the ‘Actions’ menu and select ‘Guest OS’. Then click on “Install VMware Tools…”.

You’ll see a pop-up message, click ‘Mount’. This will make vCenter mount the VMTools iso in your virtual machine so that the guest OS can access the installer.

Now, login into your CUCM vm’s console as an admin, and enter the following commands.

admin: utils os secure permissive
admin: utils vmtools refresh

You will be prompted that the tools install will reboot the machine twice. Press ‘y’ and hit ‘Enter’ to continue….

If vmtools has not ever been installed on this vm, or if the install didn’t complete, you might see a message that stating that you need to manually restart the server. If so, enter the command it shows to finish the intsall by rebooting the server.

admin: utils system reboot

After the reboots are finished, log back in as admin to your CUCM server. Enter the following command.

admin: utils os secure enforce

That’s it! Your VMtools have been updated. The updated guest OS info should now be visible when you look at this CUCM vm in your vCenter.

17 January 2020

VMware Workstation can’t run on Windows

This was fun… Lets update Windows. Okay, done. Now lets open VMware Workstation and get back to work on that vm that I needed to do something on…

VMware Workstation Pro can’t run on Windows

Check for an updated version of this app that runs on Windows.

Compatibility Assistant

What the!!! Umm, I’m not re-purchasing Workstation, I just bought it a couple months ago! 🤬 😤

If you have tried running VMware’s Workstation Player/Pro version 12 or 14 on Windows 10 1903 (or above), there’s a pretty good chance that you went through the same conversation with yourself that I did above. Apparently the release schedules for Windows 10 and for Workstation, don’t align, and older releases of Workstation will get put on a sort of program “blacklist”.

As part of a MS Cumulative Update (Sept 26, 2019; OS Build 18362.387+), it will update a database of programs that are prohibited by MS. Their “Compatibility Assistant” component now prevents older versions of Workstation from even running. So how do we get around this and use Workstation?

The best solution would be to become a paid “Advantage” member of the VMware User Group (VMUG). By spendign $200 and becoming an VMUG Advantage member, one of the biggest perks is that you get access to evaluation licenses of basically all of VMware’s products. So, you can download, install, run with the most current and non-“Compatibility Assistant” blocked version of Worstation.

Okay, so you don’t want to spend any additional money. I totally understand. In that case, the simplest way to fix this is going to be to make a registry edit. The registry edit is necessary to override the “Compatibility Asisstant” default behavior, thus allowing us the ability to run Workstation again.

  1. Backup your registry… Disclaimer: I’m not responsible for any unintentional mishaps you have while you edit your registry.
  2. Open a text editor, and copy/paste the code below into it.
  3. Save it as a ‘.reg’ file. Go ahead and name it something like “VMworkstation.reg”.
  4. Open and apply your “VMworkstation.reg” file to modify your registry.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags]
"{3d9912c3-cb54-4f34-ab71-1d429553bf96}"=dword:00000077
"{66f21bbc-149a-411b-8e11-880af7c1266c}"=dword:00000077

Note: This method is also suitable to deploy via Group Policy.

The last option available, would be to replace the “Compatibily Assistant” database file with an older version of itself. I’m personally not a fan of this method, so I’m not going to expand on it. But with a little googling you can learn how this would be done.

16 January 2020

Upgrade ESXi host using vCenter Update Manager

VMware Update Manager (VUM) is a component of vCenter has matured a lot as product since its introduction. One of my favorite parts about it is that it is now baked into the vCenter Server Appliance (VCSA). Using it makes the process of updating and patching your hosts a simple centralized task. Here we are going to use VUM to upgrade our ESXi host from v6.0 to v6.7.

1) The First thing we need to do is check the infamous “VMware Product Interoperability Matrices” to find our upgrade path. Looking at the matrix, we can see that we should be able to upgrade from any v6.0 release directly to v6.7u3.

Sometimes, depending on which version of ESXi you are running, you may not be able to jump straight to the latest release. You might need to do an incremental upgrade, stepping up through versions, until you finally land on your ‘final’ version. 

For example, in the picture above we can see that ESXi v5.5 does not have a direct upgrade path to v6.7. You would first have to upgrade the host to v6.0 or v6.5, before you make another jump to v6.7.

2) The next step is to download the bits of your ESXi iso. There are a couple places you can grab this iso from.

a) The first place you can get it from is directly from VMware.  Login into your VMware portal, in the right hand corner under “Quick Links” click on ‘Download Products’. In the search bar at the top of the page enter “ESXi” and you should see what we’re looking for in the auto-suggested dropdown, click on it.

Now look for the keyword “Product Binaries” in the search results, there’s a lot of other stuff like drivers listed, which we’re not looking for right now. Click the link, you’ll see another page with the actual download links.

b) For most folks, the above-mentioned way to find and download the ESXi iso will be fine. However, if you are running Dell hardware, then you have a second option; Download and use the Dell Customized ESXi image. It’s an ESXi iso that has all the Dell specific drivers pre-baked into it.

The Dell customization image includes: modifying files to identify Dell and Dell support, updating the ESXi image with the latest validated asynchronous drivers, and updating patches if it addresses a common issue for Dell systems.

To find this customized iso image, go to https://support.dell.com/ and enter your product serial number.

Click on the “Drivers & Downloads” tab.

Choose “Enterprise Solutions” in the Category field.

Expand the VMware ESXi link and click download on the desired version for your server.

3) Now we are finally ready to start using VUM, and we begin by importing our iso image we downloaded in the previous step. Login into your vCenter Server. From the menu, click on “Update Manager” -> “ESXi Images” -> “Import”.

Click the “Browse” button to navigate to and select the ESXi 6.7 iso image you downloaded previously. This will start uploading the file into VUM.

4) With our iso image now in vCenter, the next step is creating the baseline that vCenter will use to check if hosts are in compliance. Select the image you just imported, and click on “New Baseline”

Give your new baseline a name, such as “ESXi 6.7u3 Upgrade”, and click ‘NEXT’.

Make sure the image you imported is the one you have selected and click ‘NEXT’ again.

Verify all the summary details are correct and click ‘FINISH’.

Select “Baselines”, you will see the baseline that we just finished creating.

5) The next step is to attach the baseline we just created to an object. The two objects we can attach our baseline to is either our cluster or individual host. I’m going to show how to do it on a cluster object, but the process is the same for a host.

From the “Hosts and Clusters” view in vCenter, select either your cluster object. Go to the “Updates” -> “Host Updates” -> “Attached baselines” -> “Attach” -> “Attach Baseline or Baseline Group”

Select the baseline we created earlier and click ‘ATTACH’.

6) With our baseline attached to our cluster or host object, we are finally ready to upgrade the ESXi host itself. Or in VUM terms – “remediate the host”.

Go to the “Updates” -> “Host Updates” -> “Attached baselines”. Select the baseline you want to apply, in our case it’s the “ESXi 6.7u3 Upgrade”, and then click on “Remediate”.

Click on “Accept the license agreement” -> Click on “Next” to accept all the default options before upgrading ESXi 6.x to ESXi 6.7 -> Click on “Finish” to begin the upgrade. Your host should go into “Maintenance Mode” before it applies it’s remediation steps and completes the upgrade, click “OK”.

7) It’s time to sit back and watch the status bar do it’s thing.

8) Once the remediation has completed, you will be able to verify that your host has been upgraded and is now in compliance.

29 October 2019

Getting your VMWare Certified Associate – Digital Business Transformation Certification

The name “VMWare Certified Associate – Digital Business Transformation Certification” is quite a mouthful. Thankfully it can more easily be referred to simply as the VCA-DBT. If you are just starting on your path of VMWare certifications, then this is a great one to begin with. Earning this certification validates and proves to other that you understand the concepts of virtualization and how they can really drive a company forward.

This exam covers, at a basic and low level, all of VMWare’s products – like vSphere, vSAN, NSX, and vRealize. While it exposes you to all of their product offerings, it is not diving deep into any of them. You aren’t going to learn any complicated concepts of virtualization or even how to deploy a VM. It is merely certifying that you are aware of the VMware product line. It lets employers know that you have a sound grasp of what virtualization is, and how it can be leveraged to help the business reach its’ goals. It is also a great way to show that you are committed to learning, increasing your knowledge and applying yourself.

The exam itself is not too difficult. It is non-proctored exam, which means you can do it anywhere, from home or even from a coffee shop. The exam itself is 135 long, has 30 questions, and costs $125. VMware provides an “Exam Guide” to help you study, which is very helpful. Also, being that it is non-proctored, if you needed to you could potentially even use Google to help you answers questions if it came to that. It took me just a couple days to prep myself for the exam, and I was able to pass with no problem.

One important thing to note is that the VCA-DBT is not required for the VCP. It won’t hurt you to get the VCA-DBT, but it is in no way a prerequisite to progress towards your VCP. It is, however, a great way to get familiar with VMware’s style for exams and test taking though. It also is a great way to gain some knowledge of everything VMware can offer, which is a huge portfolio of products.

Category: VMWare | LEAVE A COMMENT