Major Update to VMware Certification Naming and Schedule VMware have announced a major shift in the naming and versioning for all certifications - alignment to the year in which a certification is earned, and a new annual release/update schedule for all VCP, VCAP, and VCDX certifications! Naming Convention Using the Data Center Virtualization (DCV) track, here's an example of the the next generation of certification names: VCP-DCV 2019 VCAP-DCV Design 2019 VCAP-DCV Deploy 2019 VCDX-DCV 2019 Certifications launched from this month will use this new convention, starting with the release of: VMware Certified Professional – Desktop and Mobility 2018 (VCP-DTM 2018) VMware Certified Advanced Professional – Data Center Virtualization Deploy 2018 (VCAP-DCV Deploy 2018) VMware Certified Advanced Professional – Cloud Management and Automation Deploy 2018 (VCAP- CMA Deploy 2018) Release Schedule As you might expect from such a naming convention, there's also a switch

I would like to inform about important issue: Intel L1 Terminal Fault Vulnerabilities which high impact to vSphere Infrastructure. That issue had been announced at 00:00 AM today (10:00 AM PDT). This new class of vulnerabilities can occur on current and past Intel processors (from at least 2009 - 2018) when affected Intel microprocessors are speculating beyond an unpermitted data access. Reference:  https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html This new class of vulnerabilities can occur on current and past Intel processors (from at least 2009 - 2018) when affected Intel microprocessors are speculating beyond an unpermitted data access. By continuing the speculation in these cases, the affected Intel microprocessors expose a new side-channel for attack, allowing a malicious VM to infer data in the hypervisor and other VM’s running on a core. The most severe of the three vulnerabilities (CVE-2018-3646: L1 Terminal Fault – VMM) im

There are 3 options basically for NTP services start and stop 1) Start automatically if any ports are open, and stop when all ports are closed. 2) Start and stop with host. 3) Start and stop manually.     1)Start automatically if any ports are open, and stop when all ports are closed: This one is the default settings which is recommended by the VMware. In this option if any ports are open the client attempts to contact the network resources of the services. Here point to be noted where if some ports are open, but the port for a particular services are closed, the attempt fails. It’s a drawback where the applicable outgoing port open then only the services begins to complete its usual task. 2) Start and stop with host: The service starts shortly after the host starts and closes shortly before the host shuts down. Much like Start automatically if any ports are open, and stop when all ports are closed. This option means that the service regularly attempts

Well, many of us has encountered the issue of VM hung status whether it’s a Windows or Linux machine.  Most of the time system admin use to restart the VM to recover from the hung state. Now, the question comes how can we identify the cause of the VM hung. Yes, we can check the same in vmware.log of that particular Virtual machine but that will give only limited information. What if we can get the memory dump of that VM to know the actual cause of hung. So, to get the memory dump of the VM we first need to get .vmss file of that VM. To get the .vmss file we need to suspend the VM by going into edit setting of the VM and select suspend VM option. Now, into the datastore inside VM folder you will find a new file which is called .vmss . Now, its quite difficult to read the .vmss file .  Now to extract it and convert it into core dump (memory dump) you can use one VMware fling tool ( Vmss2core ). Vmss2core will convert the .vmss file to coredump (memory dump) and

This article states how to change the system name or the FQDN of the vCenter appliance 6.x You may not find any way to change the FQDN from the vCenter GUI either from VAMI page of from webclient as the option to change the hostname always be greyed out. Now the option left is from the command line of VCSA appliance. Below steps will make it possible to change the FQDN of the VCSA from the command line. Access the VCSA from console or from Putty session. Login with root permission Use above command in the command prompt of VCSA : /opt/vmware/share/vami/vami_config_net Opt for option 3 (Hostname) Change the hostname to new name Reboot the VCSA appliance.   After reboot you will be successfully manage to change the FQDN of the VCSA . Note: Above step is unsupported by VMware and may impact your SSL certificate and face problem while logging to vSphere Web Client. If you are using self-signed certificate, you can regenerate the certificate with the

After the upgrade there were many bits and peace which we need to look for after that and there are chances, that some of the might break during after the upgrade. Same here I faced. I have VCD environment with 8.2 where I have upgraded my vCenter to 6.0 .  After the upgrade, I was able to connect the VCD without any issue. Now when I tried to create the vApp, create VM in VCD or making any changes into the Org VDC we were getting below error. [2f8s242a-2d74-4f00-ad90-45b4d78098ee] validation error on field ‘name’ String value has invalid format Solution: After investigation, I found the cause of this issue. In the properties of Org VCD & Provider VDC, in name section there was extra space/ white space was added which is not required. Here while trying to update. That’s the reason, it’s prompting for the validation error in the field of ‘name’ string where its not able to read the proper name of the source. Happy Sharing ...

Most of the times we have several requirement when we talk about IT environment like designing , deployment , compliance check or for Security auditing the environment. Somewhere during security auditing we require to provide several information to security team to get successful audit. One of them is the compliance of Virtual machine auditing of creation date and time. Here into this post we will explore how to get the creation date and time of virtual machine hosted into the vCenter or ESXi. To get the details we will use VMware Powercli to extract the details. By default there is no function added into Powercli to get such details, so here we will add a function of vm creation date. Below is the function which needed to be copy and paste into the Powercli. ======================================================================= function  Get-VMCreationTime  {     $vms  =  get-vm     $vmevts  = @()     $vmevt  =  new-object  PSObject     for

Last week I got an issue where customer was having issue where one of the shared LUN got disappeared from all the ESXi host. Well, while troubleshooting I found some error found in vmkernal.log 2017-11-30T06:47:09.272Z cpu78:12160496)WARNING: Partition: 1224: Partition 1 is active, failure to update partition table for naa. 600666666666666666666 2017-11-30T06:47:09.422Z cpu78:12160496)WARNING: Partition: 1224: Partition 1 is active, failure to update partition table for naa. 600666666666666666666 Try to verify if the LUN is attached to ESXi by using below command and found its connected. esxcli storage core path list OR esxcfg-mpath -l Later, Verified if the LUN status is showing online, degraded or offline by using command esxcli storage core device list -d  NAA_ID At present, I was able to see the LUN status online. However the LUN is still not visible in device section. From the vmkernal.log error which was mentioned above “WARNING: Partition: 1

Recently I got an issue where customer was not able to take snapshot also unable to consolidate the snapshot. While verifying the snapshot status of VM in snapshot manager its shows no snapshot available. However, while accessing the datastore I found 30 snapshot on both the hdd attached to the VM. I tried to consolidate the VM from snapshot manager & from ESXi cli using below command where VIMID is the VM ID which you can get from vim-cmd vmsvc/getallvms (To get vm id) command vim-cmd vmsvc/snapshot.removeall  VMID ( To consolidate the snapshot) but it again failed by giving failed status. Next, I tried to find CID and PID status of both the HDD connected to virtual machine.  You can use below command followed the path of virtual machine . (i.e /vmfs/volumes/vmname) for i in `ls -l *.vmdk  | grep -v delta | grep -v ctk | grep -v flat | awk '{print $ $i; done As mentioned, there are 30 delta files exist on both the HDD and one first HDD I find CID

Recently I had an issue where I was trying to power on a VM from vCenter but unable to power on. While powering on getting below error. “ A general controller error occurred. Connection refused .” VCenter server which Im running is 6.0 and on appliance (VCSA). Steps I follow to resolve the issue: While investigation I found it’s a issue of Workflow manager service which was causing VM to start from vCenter. However, I was able to power on the VM from ESXi, which shows that the issue is not with VM or ESXi . It’s the issue with the services of workflow, which are not allowing VM to poweron from vCenter. I tried below steps to verify the status of the VMware vCenter Workflow Manger service from VCSA. 1) Login to VCSA via Putty. 2) shell.set --enabled True 3) service-control --status vmware-vpx-workflow Status of the services was showing stoped, So, I tried to start the service by using command. service-control --start vmware-vpx-workflo