Virtualization Blog

I have seen this more on 5.5 ESXi hosts but the host shows the up time as 0 seconds and CPU and Memory percentage as 0% Easiest way to resolve this is to put the host in maintenance mode and then restart the management agents on the ESXi hosts.  #esxcli services.sh restart But to be more cleaner I prefer to put host in maintenance mode and reboot the host to get the clean state.

I recently experienced an issue with vCenter 5.5 was getting disconnected sporadically. vCneter was running on windows 2012 server. I was able to see following errors in windows logs. vCenter Logs were showing following errors -          2018-08-18T01:30:03.630-04:00 [11432 error 'Default' opID=92132b4] An unrecoverable problem has occurred, stopping the VMware VirtualCenter service. Error: Error[VdbODBCError] (-1) ODBC error: (08S01) - [Microsoft][SQL Server Native Client 11.0]TCP Provider: The specified network name is no longer available.         2018-08-18T01:30:03.630-04:00 [11432 error 'Default' opID=92132b4] An unrecoverable problem has occurred, stopping the VMware VirtualCenter service. Error: Error[VdbODBCError] (-1) ODBC error: (08S01) - [Microsoft][SQL Server Native Client 11.0]TCP Provider: The specified network name is no longer available.         2018-08-19T19:28:31.801-04:00 [06368 warning...

I was working in an environment where NSX was configured with Trend micro deep security in VDI environment to protect VDI desktops. We had 2 vCenters setup in that way and one of the vCenter is showing some odd symptoms. We are seeing some weird actions with NSX manager in one vCenter. So, I lose the connection to the vCenter from fat client, web client is still fine and doesn’t kick me off. In the process, the Guest Introspection appliance or GI VMs (appliance managed by NSX) from some  random hosts were getting deleted automatically -  from the cluster that was protected with NSX. When I checked the windows logs (as vCenter was on windows server) this is what I saw -  I opened a case with VMware support - They reviewed the NSX logs and came to conclusion that this is not the NSX issue but it's vCenter that is deleting those VMs. vCenter gets disconnected for few seconds, then connects back. It doesn't recognizes those GI VMs and starts de...

Add-PSSnapin  VMware.VimAutomation.Core    (For vSphere 5.5 or below) Import-Module VMware.VimAutomation.Core   (For vSphere 6.0 and above)   Connect-VIServer  vCenterName Get-Datastore | Select Name, @{N="NumberofVMs"; E={@($_ | Get-VM).count}} | Sort Name |Out-file "C:\Temp\VMcount.csv"

Here is a script to check Power state of a VM using power shell. Create the .csv file (vmlist.csv) with header name as "name" and list all the VMs under it, for which power state needs to be determined. Enter the appropriate vCenter name to connect to the vCenter. The list of VMs and its power state will be displayed on the screen. Add-PSSnapin  VMware.VimAutomation.Core    (For vSphere 5.5 or below) Import-Module VMware.VimAutomation.Core   (For vSphere 6.0 and above)   Connect-VIServer vCenterName $vms = Import-csv " C:\temp\vmlist.csv " foreach ($vm in $vms) { $p = get-vm $vm.name | Select-Object Powerstate $q = ($p).powerstate Write-output "$($vm.name) `t $($q)" }

Here  are the high level step to upgrade the HPE 3PAR Storage Replication Adapter (SRA) - If old SRA is visible in add remove programs -  View certificates for old array (that will be removed after migration) from SRM server using following path and TPDsrm utility -        C:\Program Files\VMware\VMware Site Recovery manager\Storage\SRA\3Parinsrv>              TPDsrm.exe viewcert Uninstall old 3PAR SRA from SRM server using uninstall program feature. Reboot the SRM server. Install new 3PAR SRA using the .exe file provided by vendor. Check if you can see the new SRA in Program list. If so, reboot the SRM server.  Validate certificates for new array using following path and command on SRM server -        C:\Program Files\VMware\VMware Site Recovery manager\Storage\SRA\3Parinsrv>               TPDsrm.exe validatecert -s...

The NSX manager was deployed and configured correctly. It was showing up in vCenter, when I configured it. After few days when I checked suddenly NSX  disappeared from the vCenter inventory. I logged in to NSX manager and it was all fine. It was showing as connected with its respective vCenter but wasn't showing up in the vCenter.  I tried to restart the vCenter services and vCenter server that did not resolve the issue. Easiest fix that worked with me for this issue is to restart the NSX manager and then it shows up back in vCenter.  

I was working in an environment that had virtual desktops (managed by horizon view) that were secured using agent less antivirus using Trend Micro Deep Security in integration with vShield manger. As vShield manager is not supported platform anymore - the plan was to migrate from vShield manager to NSX Manager and integrate it with Trend Micro Deep Security. Here are the steps that we followed in the whole process - Deploy NSX Manager from vCenter. Logon to NSX manager and configure the NTP settings for the NSX manager.  Configure the inventory services and register vCenter to the NSX manager. SSO admin credentials (e.g.- administrator@vSphere.local) are required for this configuration.  Once the inventory service and vCenter are connected successfully with NSX Manager, logon to vCenter with SSO admin credentials (the same credentials that were used to register the vCenter with NSX Manager) - Networking and Security (NSX manager) icon will pop up in vCenter. Add t...

Here are the steps for the initial configuration of VMware NSX Manager-  Deploy NSX Manager for the vCenter. NSX manager and vCenter have 1:1 binding, so if there are multiple vCenters - multiple NSX manager needs to be deployed each in one vCenter Once NSX manager is deployed, logon to the NSX manager using the IP address or the FQDN of the NSX manager Configure the NTP settings by clicking on "View Summary" on home page and then clicking Configure NTP Servers from Manage - General - Time Setting  Once the NTP time settings are configured, configure look up service and vCenter Server to connect to the NSX manager. Click on manage vCenter registration and click on configure look up service to configure the lookup service. Accept the SSL certificate. Once Lookup service is connected successfully, register the vCenter to the NSX Manager. Note - SSO admin account (administrator@domain.local) needs to be used for the configuration of look up service and registration o...

I was working on upgrading HPE 3PAR SRA from 6.1.0 to 6.5 on VMware SRM 6.1 which was installed on Windows 2012 server. It was supposed to be straight forward process. Uninstall old SRA and install new SRA using the .msi file. That's it! When I logged into SRM server (windows 2012) to uninstall the HEP 3PAR SRA old version (6.1.0.170) using control panel - uninstall program feature. HPE 3PAR SRA did not show up in the program list in programs and features. I tried to install the SRA 6.5 directly but it failed with an error - Error1001.InstallUtilLib.dll:Unknown error. Ok, so I thought of installing the 6.1 version. When I tried that it said the product is already installed on this server. Then I started digging into it more. I deleted all the entries that had HPE 3PAR 6.1.0.170 from registry, rebooted the SRM server - tried to install the SRA 6.5 - same error -Error1001.InstallUtilLib.dll:Unknown error.  Then I started looking out for Error1001.InstallUtilLib.dll:U...

We recently implemented NSX in one of the VDI environment.  The environment had vShield and trend Micro Deep Security to protect the desktops. Once we migrated from vShield to NSX, we observed that taking out the host from the NSX cluster needs to follow specific steps. If these steps are not followed in the specific order there may be possibility that the host may not be cleaned up thoroughly with NSX vibs. Here is the process that will make sure the hosts are cleaned up properly once removed from NSX cluster. Put the ESXi host in maintenance mode. The NSX agent VMs that are specific and residing on that host for NSX management, will be powered down once host is in maintenance mode. Take out the host from the cluster by dragging it out of the cluster (in the data center or in some other cluster) Wait till the NSX agent/VIB gets uninstalled from the host (you will see that in the task manager of vCenter) Once VIBs are removed by vCenter – Reboot the host ...

To check up time for windows server -  Logon to the Windows server and got to command prompt. >  net statistics server This will provide the statistics of the server since the server last rebooted. To check up time for Linux Server -  Logon to Linux server and go to the terminal.   $ uptime    This command also applies to the ESXi servers (if you have taken ssh session or shell to the ESXi host) as they are the Linux flavor.

To check up time of ESXi host from vCenter server - Logon to vCenter Server -  If using C# (fat) client - click on cluster - on right side pane click on Hosts - select the up time option by right clicking on the header. The column will be added at the end. You can drag and drop column to place it in your view. If using HTML client - click on cluster - on right side pane click on Hosts - select the up time attribute from show/hide column by clicking on the header  If using web (Flash)  client - click on cluster - on right side pane click on related objects - hosts - right click on the header to show/hide column - click on up time attribute Similarly,  you can check the up time for a virtual machine by clicking on the virtual machine tab instead of host tab, but only caveat  is vCenter gives you up time of a virtual machine according to reboots performed from the vCenter. So, rather than rebooting server fr...

In one of my labs all the hosts and VMs are on the VMware distributed switch to mimic one of the production environment. When I planned for the upgrade from vSphere 5.5 to 6.5 in that lab and started deploying the VCSA 6.5 using the .iso image - I came across this.  So, VMware doesn't support distributed switches with non-ephemeral port group when deploying the VCSA and PSC on 6.5. I read few articles and most of them suggested to migrate your vCenter 5.5 to Standard switch as well as build the new VCSA 6.5 on standard switch for smooth migration.  But what if environment is 100% on distributed switch and going back and creating standard switch is not an option. Well, there is a work around to get past this screen. You will need to create a port group on distributed switch with "ephemeral binding".  Once you create that port group on the distributed switch, all the VLANs/port groups from that distributed switch would show up and you can deploy ...