Skip to main content

Posts

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

Unable to take snapshot & consolidate the VM

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

A general controller error occurred. Connection refused while powering on virtual machine

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

Migration Assistance (Migrating Windows vCenter to VCSA 6.5 )

Migrating vCenter from one version to another was always a complected task earlier. With the introduction of migration assistance tool which was introduced in 6.0 u2 version,life of the administrator become far easier without worried about multiple components configuration task during migration as most of the task performed in this tool are automated. The risk of mistake and miss-configuration has become lesser during deployment. So, lets gets started.  Here we are migrating windows based vCenter with embedded PSC to VCSA 6.5 Download the ISO or binary of VCSA 6.5 from the VMware portal. Once you have ISO of VCSA mount it into vCenter. Step 1 Run the migration assistant tool which is present under  <Mounted Drive>:\migration-assistant\VMware-Migration-Assistant Note: This "Migration-Assistance tool need to be executed on windows vCenter and once run, it will automatically detect the vCenter instance runing on the machine. Step 2 Once the administrat

To change the ESXi root password when ESXi host managed by VCD

Recently we got into the issue where I have to change the ESXi host root password which was managed by the vCloud Director. Changing the root password directly from the ESXi host is not recommended when the ESXi host is managed by vCloud Director. All operation task need to be accomplish through vCD. NOTE: The test was done on both the ESXi hosts in maintenance mode from VCD and with taking them in to maintenance mode. Since you are performing the ESXi root password change I would suggest to  perform during maintenance mode. Steps performed to change the root password of the ESXi host. Step 1) Enable or Disable an ESX/ESXi Host: You can disable a host to prevent vApps from starting up on the host. Virtual machines that are already running on the host are not affected. - To perform maintenance on a host, migrate all vApps off of the host or stop all vApps and then disable the host. Procedure: 1. Click the Manage & Monitor tab and click Hosts in t