As part of some automated deployment work for ESXi I was assisting a colleague with, they had hit an issue with an out of the box deployment of ESXi beginning with a blank password for the root account.
The automation tool of choice Ansible was using an SSH connection to ESXi to make the initial configuration and was blocked at the first step since it was unable to connect because the fresh ESXi install had no password set.
While working with Nested ESXi in my lab, I had an issue where I could communicate with the IP address on vmk0, but after adding multiple additional VMkernel Ports could not communicate with any of the additional IP addresses. It’s a simple network for testing, everything on the same subnet and no VLANs involved.
I hadn’t done too much reading on the subject before, other than knowing I needed to implement Promiscuous Mode for the Port Group on the physical ESXi servers.
Synology enabled VAAI support for NFS in version 5.1 of their DSM software. In order to take advantage of this technology from ESXi hosts we need to do two things:
Upgrade DSM to at least version 5.1-5004 (2014/11/06) Install the Synology NFS Plug-in for VMware VAAI DSM
DSM can be upgraded from within the Control Panel application. Head to the Update & Restore section, check for and install updates. This will likely require a reboot so ensure anything or anyone using it is shutdown or notified.
During setting up an iSCSI LUN on my new Synology box (DSM 4.3), I encountered an issue where the first ESXi box would connect successfully to the iSCSI target, but not the second. So no devices showing on the second node after configuring the iSCSI adapter, despite no apparent errors during the config process.
Looking at the Synology box showed the first ESXi node connected (172.20.0.210), but not the second.
Whatever backup solution you use to backup your virtual infrastructure with, you may sometimes end up with VM snapshots that need to be cleaned up. After a backup failure alert, I use the following PowerCLI one-liners to quickly identify and remove snapshots left behind (by say Netapp SMVI).
Get-VM | Get-Snapshot | Where-Object {$\_.Name -like 'smvi\*'} | ft VM,Name,Created -AutoSize Get-VM | Get-Snapshot | Where-Object {$\_.Name -like 'smvi\*'} | Remove-Snapshot -RunAsync -Confirm:$false Recently I had an instance where post a backup failure the snapshot failed to remove with the error Unable to communicate with the remote host, since it is disconnected.
Having recently enabled Storage DRS in a vSphere 5.1 environment we began to see a lot of the following errors in vCenter:
The device or operation specified at index ‘x’ is not supported for the current virtual machine version ‘vmx-04’. A minimum version of ‘vmx-06’ is required for this operation to succeed
The host(s) running the VM(s) in question contained the error matched in this VMware KB article:
[2009-07-10 14:13:41.632 F638BB90 info ‘vm:/vmfs/volumes/4a56e6c2-9319e3df-f1af-001e0bea4030/RVHOLS029/RVHOLS029.
This one tripped me up earlier in the week, so thought it was worth sharing in case you hit the same issue sometime. In PowerShell v2 and earlier when using Get-Credential to save credentials into a variable and NOT using a full Windows domain credential, e.g. something like:
instead of a more Windows style credential:
then the resultant stored credential prepends a \ in front of the username:
$cred = Get-Credential PS C:\\> $cred UserName Password -------- -------- \\root System.
After upgrading a Cisco UCS C210 M2 rack mount server to ESXi 5.1 and then ESXi patches from 25/07/2013 the host was stuck at ‘Initializing scheduler….’
I had checked my firmware version was satisfactory for ESXi 5.1
but found reports suggesting this (intermittent) issue has been around for a while with earlier versions of ESXi, different versions of UCS models and firmware and maybe HP models too.
Before trying the suggested workaround of disabling legacy USB support, I decided to get the box up to the latest firmware.
A colleague of mine demonstrated this for me yesterday while we were troubleshooting which physical NIC out of 8 in a rack mount server matched up to which vminc (0 - 7) in vSphere. Tougher than you might think when vmnic6 and 7 mapped to the onboard physical NICs 1 and 2!
Using the command line tool ethtool you can make each vmnic blink for a specified period of seconds allowing you to identify which port on the back of the server it maps to.
I needed to check the configuration of all hosts in an environment for their ESXi Dump Collector Settings and then ensure they were all set to the correct values. I was using the handy ESXi Dump Collector which ships as part of the vCenter 5.1 package.
There are no PowerCLI cmdlets for doing this (yet) so I made my own, Get-VMHostDumpCollector and Set-VMHostDumpCollector. Since you can get and set this item via esxcli I used the Get-ESXCli cmdlet for most of the work.