Skip to main content

Posts

Total Logon Time metric display "No Data" in vRops for Horizon dashboard

Last week I was working with one of my customer who has recently upgraded their vRops environment to 6.7 version.  Their environment consist of  VDI environment running on VMware Horizon. Here in vRops environment they have default Horizon dashboard as they have configured Horizon adapter for their VDI environment. From some time we are getting issue into Horizon dashboard where they were not able to see Total Logon Time metric display where its display "No Data" as seen below To resolve the issue of " No Data" there is a solution which works for me and recommended by VMware. This issue identified when we not enable the time profiler. The logon time is calculated by 'First_idletime - logon_starttime' The 'logon_starttime' is retrieved from DB and 'first_idletime' is retrieved from DA (Desktop agent). Its because the DB is not consistent with DA. This will cause the "logon_startime" be sm

Issue with VMware Tools 10.3.0

There is an issue identified with VMware Tools 10.3.0 release that can cause the ESXi host to PSOD. Multiple issues, including the PSOD,  have been brought in attention with the VMXNET3 driver that shipped with the VMware Tools 10.3.0 release. In response to this, VMware is puling this release from availability through myVMware. In order to be exposed to these issues, all of the following must be true: ·        Windows 8/Windows Server 2012 or higher ·        VMXNET3 network adapters in the VM hardware configuration ·        VM Hardware version 13 ·        ESXi 6.5 hosts ·        VMware Tools 10.3.0 installed ·        VMware Tools 10.3.0 includes the applicable VMXNET3 driver version. ·        The problematic VMXNET3 driver is version 1.8.3.0 VMware been made aware of issues with the VMXNET3 driver released in VMware Tools 10.3.0, and that we recommend downgrading to VMware Tools 10.2.5 for the configurations outlined above. You may also refere

Major Update to VMware Certification Naming

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

LT1F Vulnerability (L1TF) VMware

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

Options for NTP services in ESXi

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

VM in Hung status

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

Changing the FQDN of the vCenter appliance (VCSA)

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

Validation error on field ‘name’ String value has invalid format

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 ...

VM Creation Date & Time from Powercli

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

LUN VMFS partition table corrupted

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