1).

vSphere Web Client HTTP Status 404 The

requested requested resource is not
available
It is often standard practice to install the server operating system on C: and then applications and
data on additional drives such as E:, F: and so on.

However vSphere Web Client since its 5.0 release though 5.1 and including the latest version at time
of writing 5.5 U2, if you install vSphere Web Client to any directory other than the default installation
directory you will get the following error when browsing to the vSphere Web Client page.

"HTTP Status 404

The requested requested resource is not available"

I've seen this problem for a while now and just tried latest release 5.5 U2b hoping it had been
resolved (I couldn't find a reference in the release notes).
Unfortunately it is still a problem and while the rest of the components such as Single Sign On,
Inventory Services and vCenter Server can be installed to another drive letter or directory, the
vSphere Web Client must still be installed to the default directory of C:\Program
Files\VMware\Infrastucture

If you've installed vSphere Web Client to anything other than the default directory and getting the
error above, the only way to resolve this is to uninstall and re-install to the default installation
directory provided by the wizard.

Fingers crossed it gets fixed in vSphere 6.0!

2).How to Reset the Password

for admin@System-DomainvCenter SSO
5.1 (Single Sign On)
If you are in the unfortunate position in which you or someone else has forgotten the vCenter SSO
v5.1 admin@System-Domain password, then you may have a problem. Particularly if there are no
other users delegated as SSO administrators.
However the aim of this blog post is to help you in resetting the admin@System-Domain password in
SSO 5.1 only (it is much easier in 5.5)!.

First and foremost it's worth pointing out this is completed unsupported by VMware. VMware's
advise and supported method is to reinstall SSO.

However you do have 2 other possible options I have presented below.

The first options is to simply check the password for the SSO DB in clear text which may be the
same as the SSO admin user password.

The second is to update the SSO SQL database admin users password hash, to essentially change
the password hash to a password has we know and will change later.
Option A - If your lucky you might be able to find the password this way..

1. Check this file to see if the password used for the SSO SQL database user was the same as the
password used for "admin@System-Domain"
C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-
INF\classes\config.properties
Note: You will need to change the drive letter to where you install vCenter SSO to if different to C:

2. The password used for the SQL Server database is on this line "db.pass="

## Jdbc Url
db.url=jdbc:jtds:sqlserver://;serverName=;portNumber=1433;databaseName=sqldb1sso
## DB Username
db.user=svcvc1sso
## DB password
db.pass=Password123
## DB type
db.type=Mssql
## DB host
db.host=sqldb1.vmadmin.co.uk

Option B - This should work if you do not know the SSO master password for
"admin@System-Domain" and wish to reset it..

1. Open SQL Server Management Studio and connect to SQL server hosting SSO (RSA) database

2. Backup the SSO RSA database so you can restore it if there is a problem
3. Run the following SQL script on the SSO RSA database to set the "admin" users password hash
to "VMware1234!"
Note: You can change the password later, for now we will set it to the above password to save re-
installing SSO.

UPDATE
[dbo].[IMS_PRINCIPAL]
SET
[PASSWORD] = '{SSHA256}KGOnPYya2qwhF9w4xK157EZZ/RqIxParohltZWU7h2T/VGjNRA=='
WHERE
LOGINUID = 'admin'
AND
PRINCIPAL_IS_DESCRIPTION = 'Admin';

3. If you try to login to vSphere Web Client at this point you may get the following message about
your password has expired.

"Associated users password is expired"

4.Open an elevated command prompt and run the command:
SET JAVA_HOME=C:\Program Files\VMware\Infrastructure\jre
Note: Do not put quotes round the path and change the directory to the path you installed vCenter to

5. Navigate to the ssolscli directory (change to the directory you installed vCenter SSO to)
cd "C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli"

6. Run the SSOPASS command to remove the password expiry

ssopass -d https://vcenter1.vmadmin.co.uk:7444/lookupservice/sdk admin
Note: This has to be the FQDN the certificate was generated for, localhost will not work.

7. Type your current password, even if it is expired.

8. Type the new password, and then type it again to confirm.

9. Now you can logon to the vSphere Web Client with the following credentials:
admin@System-Domain
VMware1234!

10. Change the password for the account and keep a record of it!

11. It would also be adventageous to add a domain user or group to the SSO administrators group.

3).The operation is not allowed in the

current connection state of the host -
Power on VM vCenter 5.5

I just had an issue with vCenter 5.5 and ESXi 5.5 where I was unable to power on a VM.

The error which I was faced with was a relatively generic message based on the host connection
status.
"The operation is not allowed in the current connection state of the host"

The ESXi server itself was connected to vCenter and had a number of VMs already powered on and
working correctly.

However I noticed that the CPU and Memory utilisation statistics for the ESXi server were showing
as zero "0" used, odd because there were 3 VMs already powered on using CPU and memory
resources.
With my running VMs still powered on, I disconnected this host from vCenter (waited about 1 min),
then connected the host back to vCenter.
The ESXi server CPU and memory statistics were now showing correctly for my powered on VMs.

Attempting to power on a VM is now successful.

This is the first time I have seen this host connection issue with vCenter 5.5, if it happens any more I
will update my comment here and report a bug to VMware.
 Host Profile - HA DRS Cluster Non
Compliant - FT logging is not enabled

Compliance of a cluster is checked based on various factors, depending on if you have HA enabled,
DRS enabled or both!

HA and DRS
 FT logging NIC speed is at least 1000 Mbps.
 At least one shared datastore exists.
 FT logging is enabled.
 VMotion NIC speed is at least 1000 Mbps.
 All the hosts in the cluster have the same build for Fault Tolerance.
 The host hardware supports Fault Tolerance.
 VMotion is enabled.

DRS only
 VMotion NIC speed is at least 1000 Mbps.
 VMotion is enabled.
 At least one shared datastore exists.

HA only
 FT logging NIC speed is at least 1000 Mbps.
 At least one shared datastore exists.
 FT logging is enabled.
 VMotion NIC speed is at least 1000 Mbps.
 All the hosts in the cluster have the same build for Fault Tolerance.
 The host hardware supports Fault Tolerance.
 VMotion is enabled.

The most common problem is that when HA is enabled on a cluster (with or without DRS enabled) one
requirement is "FT logging is enabled".
FT (Fault Tolerance) is not that widely used so the chance you set this up is unlikley (and is not require
for HA to work) so this is a bit a false check as we might not want FT!

To disable the checking of FT for the cluster complance check this is simply and advanced option in the
HA settings..

1. Simply right-click Edit Settings on your cluster

2. Select vSphere HA and click the "Advanced Options" button

3. Enter the option "das.includeFTcomplianceChecks" and a value of "false".

4. Click Ok, Ok.

5. Rescan you cluster for compiance and hey presto!

Host Profile Issue with local SAS drives -
Specification state absent from host
There are numerous reasons to use vSphere host profiles, namely to ensure all your ESXi hosts
within a cluster are configured identically.

Storage of course is an important part of this, as we need to ensure all hosts can see the same
datastores, the same pathing policy configured etc.

If not we want an alert to tell us this so we can correct - even perhaps automagically with host
profiles!

However local SAS drives within the ESXi server can be detected as remote storage devices, which
as you can imagine can cause an issue with this compliance checking.

If this is the case the local SAS drive "naa.xxxxx ID" needs to be presented to each ESXi server to
tick the compliance box, but thats not possible as it's a local disk.
 In such case you wll come across the following errors in your host profile checks. Attempting to
remediate will not resolve the problem.

 Specification state absent from host: device '<datastore>' state needs to be set to 'on'
 Host state doesn't match specification: device '<datastore>' needs to be reset
 Specification state absent from host: device '<datastore>' Path Selection Policy needs to be set to
'VMW_PSP_FIXED'
 Host state doesn't match specification: device '<datastore>' Path Selection Policy needs to be set to
default for claiming SATP


To my knowledge there is no way of getting the local SAS to disk not show as remote storage so all
you can do is disable this part of the check in the host profile.

1. In vSphere client under Home --> Host Profiles select Enable/Disable Profile configuration.

2. As in the image below, go to Storage Configuration

3. Native Multi-pathing (NMP) --> PSP and SATP confiugration for NMP policies, untick "PSP
configuration for"
4. Pluggable Storage Architecture (PSA) configuration --> PSP and SATP confiugration for NMP
policies, untick "PSA device configuration"

5. Click Ok and Rescan your cluster for compliance

6. Your cluster should now be complaint remove the 4 device naa device compliance issues.
Removing the Cisco Nexus 1000V vSwitch
This is a guide to removing the Cisco Nexus 1000V DVS and VSM virtual machine cleanly from your
hosts and vCenter Server.
DO NOT TRY TO DELETE THE NEXUS DVS OR VSM VM DIRECTLY!! This needs to be
performed in a specific way (very strightforward when you know how), the DVS is removed via the
the Nexus VSM so this is the last part to be deleted - Don't do it first!

1. Login to vCenter and browse to your Cisco Nexus 1000V dvSwitch.

2. If you have not done so already ensure they are no VMs connected to the Nexus DVS port
groups.
If there are still VMs connected to the Nexus 1000V port groups you need to migrate them all to
another vSwitch/dvSwitch port group now.
Of course you will need to make sure the the new port groups are configured as required and any
physical uplinks have the correct settings such as allowed VLANs etc (but thats out the scope of this
article).

3. Remove the ESXi hosts from the Nexus vSphere Distributed vSwitch.
This is a pretty simple step and performed the same way as a normal dvSwitch.
Provided there are no VMs connected to the dvSwitch then this remove operation will complete
successfully, if not you will need to see whats still connected.

4. Confirm the removal of the host from the DVS.

5. A vCenter task will run removng the host from the dvSwitch confirming this.
6. Repeat the removal of each ESXi server from the Nexus 1000V dvSwitch.

7. If you try to right-click remove the Nexus dvSwitch from vCenter at this point you will get
the following error message:

"Cannot remove the object, since it has active related objects"

Don't get ahead of yourself! We need to unrelate the Cisco Nexus 1000V VSM from vCenter first,
which then removes all the dvSwitch port groups, uplinks and switch automatically for us.

8. Connect to the Cisco Nexus 1000V VSM either via SSH or VM console
9. Check that the Cisco Nexus 1000V VSM is connected to vCenter Server
If the VSM is not connected to vCenter the next operations will fail to remove the DVS.
Ensure that the operational status and sync status are "connected" and "complete" by running "sh
svs connections"
If its not connected try pinging, checking the vNIC is connected, reboot the VSM to see if it
reconnects at boot etc.

NEXUS1000V-VSM# sh svs connections

connection vcenter:
ip address: 172.123.123.123
remote port: 80
protocol: vmware-vim https
certificate: default
datacenter name: Datcenter
admin:
max-ports: 8192
DVS uuid: 1b a2 1e 50 f4 83 48 68-c7 cf e4 61 a0 01 03 88
config status: Enabled
operational status: Connected
sync status: Complete
version: VMware vCenter Server 5.0.0 build-455964
NEXUS1000V-VSM#

10. Remove the DVS from vCenter

Thiis where the magic happens, removing the port groups, uplinks, dvSwitch and folder, run the
following commands on the Nexus VSM below:

NEXUS1000V-VSM# conf t
Enter configuration commands, one per line. End with CNTL/Z.
NEXUS1000V-VSM(config)# svs connection vcenter
NEXUS1000V-VSM(config-svs-conn)# no vmware dvs
This will remove the DVS from the vCenter Server and any associated port-groups. Do you really
want to proceed(yes/no)? [yes] yes
Note: Command execution in progress..please wait
NEXUS1000V-VSM(config-svs-conn)# exit
NEXUS1000V-VSM(config)# exit
NEXUS1000V-VSM#
11. After running the above commands you will see vCenter Server kick off a number of
tasks, removing the port groups and finally the Cisco Nexus 1000V DVS.

12. Remove the Cisco Nexus 1000V VM(s)

Once you have confirmed the dvSwitch has been removed above you can delete the VSM VM.
Right click the VM and Delete.
If you have a VSM in HA (i.e. a primary and secondary VM) delete both VMs.

13. Now we are almost there but there is still a plugin showing in plug-in manager that needs
removing. Note down the unique plug-in name e.g. "Cisco_Nexus_1000V_590855575"

14. Open up IE and browse to the vCenter MOB (Managed object browser)

15. In the "Properties" section, Click on "Content"

16. Click on "ExtentionManager"
17. In the list of extentions you will see the plug-in you noted earlier

18. In the "Methods" section, Click "UnregisterExtension"

19. Now copy/paste in your extentionKey and Click "Invoke Method"
e.g. Cisco_Nexus_1000V_590855575 (yours will be unique - without quotes)
20. Hurrah the plug-in has now been removed!

21. Close and re-login to vCenter with the vSphere Client, you will now also see the plug-in
has been removed from plug-in manager.
And there we have it - The Cisco Nexus 1000V dvSwitch and VSM have been successfully removed
correctly, including the vSphere plug-in.
vCenter Server 5 Install/Upgrade Warning -
The Fully Qualified Domain Name cannot
be resolved

Whilst performing clean installaions and upgrades of vCenter Server 5, I have come across the
following warning message on a number of occasions.

"The Fully Qualified Domain Name cannot be resolved. If you continue the installation, some
features might not work correctly."
The vCenter server installer is performing a reverse DNS lookup and confirming if there is an entry
for the server. In this case it has failed.

All you need to do is first confirm if infact a reverse lookup zone exists on the DNS server. This most
likley will be on an Active Directory Domain Controller and replicated too all other DCs in the
domain/forest. So a single point of config can add this for all DNS servers if there are more than one.
Go to your DNS server and add a new reverse lookup zone for the IP range that the server exists in.
You will notice your server still does not appear in the reverse lookup zone.
Next we need to request the server to register its adaptors in DNS updating the records already held
and not - in this case our reverse lookup zone record.

ipconfig /registerdns
Refreshing the DNS Manager console will now show the pointer record for this server in its reverse
lookup zone.
Pressing backing the back button then next again will confirm this issue is now resolved. If the
reverse lookup was still not working correctly this test would fail again and the warning dialog would
be shown again.

Happily now continue the installation/upgrade....

vCenter Server Database Retention Policy -
Events and Tasks
As time goes by your vCenter database will grow, its a fact we all know and accept. However we
dont want to retain unnecessary old data in the database which causes disks to eventually fill up and
backups to for run longer periods. So what can we do about it? Change the vCenter database
retention policy of course...

Everytime a task or event is created it is stored in the database.

For example a task is created when powering on a virtual machine.

An event would be created when something occurs such as cpu usage for a VM changing to red.

In most cases for each task an event is created, such as powering off a VM in the example below.
Fortunatley the retention period for tasks and events can be changed (individually too!)

1. In vSphere client go to (Administration --> vCenter Server Settings).

2. Check the database retention policy

Go to "Database Retention Policy".

The default retention policy is to keep tasks and event indefinatley.

3. Change the retentention policy as required

PCI-DSS compliance requires logs/records to be kept for up-to 1 year.

To change this so to reduce the database size while remaining compliant, set the retention period to
365 days for both tasks and events.

Click Ok, and there you go, you have now limited the growth of the database.
Error Applying Host Profile - IP address is
used for multiple virtual nics
I had created a host profile from an identical server (NICs etc) and applied to a fresh install of ESX 4.
However it failed for a couple of reasons half way though applying. At this point it had converted
the standard virtual switch (SVS) to several DVS distributed virtual switches (DVS), and moved the
pNICs as part of this. After correcting the problem I went back to continue to apply the profile to the
server to complete the remaining parts (firewall etc) however I received the following error:
"IP Address <ip.add.re.ss> is used for multiple virtual nics"

There was little to no information about this occuring for anyone so this is what I did...

1. First remove a pNIC from a DVS (or use a spare).

2. Create a new standard virtual switch (SVS).

3. Add the pNIC (from the DVS or the spare) to the SVS.

4. Migrate the Service Console "vswif0" from the DVS to the SVS using the "Migrate to Virtual
Switch" option under "Manage Virtual Adaptors" in the DVS.
5. This should correct the problem of multiple virtual nics being defined and allow the host profile to
apply correctly.

Insufficient Memory Resources When

Powering on a VM

When powering on a virtual machine you may get the following error relating to resources:

"Insufficient memory resources"

This has occurred because the virtual machine has a minimum amount of memory assigned to it.

For it to be able to power on, there has to be sufficient memory available.

Aside from having enough physical memory and options for overcommitment, page sharing etc...
Resource pools are a very common cause of this issue.

In this example the virtual machine is part of a resource group.

Resource pools can be created with specific reservations and limits.

Here we have a resource pool with its limit set to unlimited.

However its reservation is at 0 Mhz and 0 MB with expandable reservation off.

By having it configured this was there is no resources available in the pool.

To power on the VM the resource pool needs at least enough memory the VM is configured for (in
this case the VM is set to 512 MB Memory).
 To solve this problem two different routes can be taken.

 Expandable reservation can be turned on for the resource pool and this will then use the parent or
root resource pool.
 Configure the correct amount of resource reservation (with surplus if required) for the virtual
machines that are to be powered on in the resource pool.
After configuring the correct resources for the resource pool and hence the virtual machines within it,
the virtual machine can now be powered on.

vCenter Service Not Starting - Service

Dependancies such as SQL Server
After rebooting the server running vCenter, you find you cannot log into vCenter with vSphere client.
On further inspection you find the "VMware VirtualCenter Server" service is not running (even though
it is set to automatic). However you can start it manually, it just will not start automatically after a
reboot.

Event ID 1000 explains in the description, it could not get the configuration from the
database:
Event Type: Error
Event Source: VMware VirtualCenter Server
Event ID: 1000
Description:
The description for Event ID ( 1000 ) in Source ( VMware VirtualCenter Server ) cannot be found.
The local computer may not have the necessary registry information or message DLL files to display
messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this
description; see Help and Support for details. The following information is part of the event:
Error getting configuration info from the database.
Additionally you may see the following events:
Event Type: Error
Event Source: MSSQLSERVER
Event ID: 17187
Description:
SQL Server is not ready to accept new client connections. Wait a few minutes before trying again. If
you have access to the error log, look for the informational message that indicates that SQL Server
is ready before trying to connect again. [CLIENT: <local machine>]

Event Type: Error

Event Source: Service Control Manager
Event ID: 7024
Description:
The VMware VirtualCenter Server service terminated with service-specific error 2 (0x2).
Event Type: Error
Event Source: Service Control Manager
Event ID: 7001
Description:
The VMware VirtualCenter Management Webservices service depends on the VMware
VirtualCenter Server service which failed to start because of the following error:
The service has returned a service-specific error code.

This occurs if you are running the vCenter database (SQL Server) on the same server as vCenter
itself.

As the server starts up it starts SQL Server, but this may take sometime. While this is taking place
vCenter services try and start, in doing so attempts connecting to the SQL Server database (which is
not ready) hence the event ID 17187. Finally it fails to start the service.

This is what is known as a race condition. vCenter is trying to start before SQL Server which it
depends on. If you have your SQL Server on another server this will not be a problem.

Checking the service properties tab will confirm the dependancy does not exist for SQL Server.
It resolve this we need to create dependancies for the"VMware VirtualCenter Server" service for the
following services:

MSSQLSERVER

ADAM_VMwareVCMSDS (If using vCenter Server 4)

By doing so will ensure the "VMware VirtualCenter Server" service starts after its required services
have started.

Create a Service Dependancy:

Click Start--> Run.
Type "services.msc", Click Ok.

Find the services (service names) required for vCenter to start (MSSQLSERVER and
ADAM_VMwareVCMSDS).

Click Start--> Run.

Type "regedit", Click Ok.

Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd.
Edit the "DependOnService" key and add the service names required.

Close Regedit.

Checking the service properties tab will confirm the dependancy is now configured.
From now on when you reboot the server, the VMware VirtualCenter Server service will wait until is
dependancies have started before it tries to start.

Alarms and Email Alerts from vCenter

vCenter comes with a few default alarms such as ESX host connection state and usage alarms.
These are useful but only are visible if you are logged into vCenter with VI Client.

However it can be configured so that you get email alerts when these alerts trigger between a
certain status.

At the "Hosts & Clusters" level click on the "Alarms" tab.

Change the view button to "Definitions".

Choose the Alarm you want to setup and email notification for right click "Edit Settings".
In the Alarm Settings dialog go to the "Actions" tab.

Add an action to "Send a notification email" and set an email address as the value.

Tick the status changes you want to be emailed about. Click Ok.

Now when there is a status change in the defined trigger you will receive an email alert.

Note: Be sure you have set an SMTP server in the virtualcenter configuration under the
administration menu.

Deploying from a Template and Using

Guest OS Customization
Templates can be very useful in reducing time to deploy a virtual machine and ensuring that it is built
to a certain standard.

Say you have a test server that you are constantly deploying to test various senarios.
Installing the OS, applications and configuring it can be very time consuming. After a while even
though you have done it a thousand times you forget to do something in the right order and have to
start over.
This is where templates will make you sane again.

What you would do is create the perfect virtual machine:

Install the OS
Fully patch the system
Install applications/configure etc

Now convert this VM to a template.

A task will show when this is complete (it only takes a few seconds for this change).

Switch to the "Virtual Machines And Templates" view so you can now see your template.

You will see the template has a different icon to a virtual machine.
Now right click the template and select "Deploy Virtual Machine form this Template".
The Deploy Template Wizard will appear.
Give the VM a suitable name and location. Click Next.

Now you could either not customize the template or customize it.
If you choose not to customize the VM it will have the same SID and other settings as the original
VM. If you deploy several VMs from this template they will conflict with each other, but the option is
there.
We want to customize the VM deployed from this template so choose "Customize using the
Customization Wizard". Click Next.
Now the Guest Customization Wizard appears. This will look familiar if you have used sysprep or
infact install windows before.
Enter the Name and Organization. Click Next.

If you prefer to have VM and OS computer names the same, choose "Use the virtual machine
name". Otherwise give another name for the computer. Click Next.
Enter licensing details, for servers tick the box for licensing mode (per seat/per server). Click Next.

Enter the password and confirm. You can optionally auto login as administrator if you wish. Click
Next.

Set the timezone. Click Next.

It is possible to run commands during the customization, if you want to do this now is the time to
enter them. Click Next.
Configure the network settings. Click Next.

Configure the domain/workgroup settings. Click Next.

You can also save this specification for deploying these settings without having to enter them again.
Click Next.

Review guest customization settings and click Next.

Review template settings and click Finish.
 The VM will now be created and configured to the defined settings. It will take sometime to first copy
the template and then customize the OS. During the customization process the OS will reboot
several times before completing.

Maintenance mode stuck at 2%

Maintenance mode can get stuck at 2% progress when there are still active VMs running on that
ESX host. An ESX or ESXi Server will not complete going into maintenance mode until there are no
running VMs running on it.

If you have HA configured it should automatically vmotion off the VMs to another ESX host with
enough resources. If your also using DRS it will do some load balancing and also work out any
affinity rules.

What can stop VMs from vmotioning automatically to another host is:
 CD/Floppy still attached to VM - If so remove it
 The virtual machine vNIC is attached to an internal only network or a vSwitch not available on
another ESX server - Check spellings of vSwitches and which network type the VM isconnected to.
 VMtools currently installing in the Virtual Machine - Wait for install to complete or cancel the
installation.
 The virtual machine is stored on a datastore local to that ESX host - The VM needs to be on a
centralized datastore (SAN etc) that is availble to another ESX host.
I have also found in a cluster of two hosts (even in VC 2.5 u3 and ESX 3.5 u3) it does not
automatically migrate the VMs, and needs to be done manually. This used to work in u1 but was
changed from u2 onwards to make harsher HA calculations, hence HA does not allow the VM to be
auto migrated to another host.

License Server - Showing incorrect number

of licenses
I found a problem with the way the license files are generated by VMware and read by the license
server.

I was checking the current licensing numbers via VirtualCenter and the FlexLM license server. It was
showing there were 8 x 1/cpu for each product (ESX, HA, DRS etc). This is double what it actually
shows in the license portal.

I double checked what I was supposed to have and it is indeed 4 x 1/cpu licenses. I have found that
each time a license file is generated via the vmware portal, if the license file is added with the old
one and reloaded, it adds the licenses together, hence 8.

Now I know the cause, I have removed all the files and just have the one generated license file now
which is correct (4 x 1/cpu).

I made VMware support aware, as anyone out there who is not so honest may be able to take
advantge of this licensing flaw.but it took some explaining to two different people. One first said that
it is supposed to show as double in VirtualCenter! Anyway if you inherit a VI from anyone and see
more licenses than you thought you had, its probably not right, check it.

Share this blog post on social media:

Files that make up a virtual machine

The following files are associated with virtual machines:

.vmx Virtual machine configuration

.nvram VM BIOS
.vmdk Virtual disk
.vmsd Dictionary for snapshots and associated disk
.vmss Virtual machine suspend file
-Snapshot#.vmsn Virtual machine configuration of a snapshot
-flat-vmdk Disk that contains the data
-f001.vmdk First extend of preallocated disk split into 2gb files
-s001.vmdk First extend of growable disk split into 2gb files
-delta.vmdk Snapshot differences file

When a virtual machine is created and not powered on, these are its files:

When a virtual machine is powered on, these are its files:

When a virtual machine is powered on ans has a snapshot, these are its files:

Licensing - Installing and updating licenses

in VI

1. Login to the VMware website and download the license file (.lic) from the account area.

2. Login to the vCenter Server or server running the FlexLM license service. If updating the licenses
save the current license file in C:\program files\vmware\vmware license
server\licenses\vmwarelicense.lic to a backup directory such as C:\program files\vmware\vmware
license server\licenses-backup\

3. Put the new license file in C:\program files\vmware\vmware license server\licenses\

4. Open Flex License Manger (Start -->Programs --> VMWare --> VMWare License Server -->
VMware License Server Tools)

5. Select the "Start/Stop/Reread" tab.

6. Click "Stop Server".

7. Click "Start Server".

8. Click "Reread License File".

9. You will see your license file information in the "Server Status" tab, review this for correctness.

10. Restart the "VMWare License Server" service.

11. Restart the "VMWare Virtual Center Server" service.

12. Log into Virtual Center with VI client. Go to Administration --> VirtualCenter Management Server
Configuration. Untick "Evaluate VirtualCenter Server". Set the location of your license server and if
you want these setting to apply to all ESX hosts. Click "OK".

13. Click on the "Admin" button and go to the "Licensing" tab.

14. Refresh the page. The new licenses will now be shown.

DRS Rules - Keeping VMs on and

seperating VMs across physical servers
It is possible within Virtual Center using DRS to ensure virtual machines are always on seperate
physical hosts. It is also possible to make virtual machines stay together on the same physical
server if you needed that.

You might want to do this if you have a microsoft cluster in virtual machines and want to ensure that
both cluster node VMs are always on different physical servers. In the meantime you can also
benefit from vmotion using DRS of these virtual machines to other physical ESX servers, provided
that they are seperate.

1. Right click on the DRS cluster that contains the VMs you want to keep together or seperate.

2. Choose "Edit Settings.

3. Under "VMware DRS" click on "Rules".

4. If any rules already exist you will see them here. To create a rule click "Add".

5. A dialog box will then be displayed. Enter a name for the rule.

5. Choose the type of rule "Seperate virtual machines/Keep virtual machines together".

6. Click "Add" to select the virtual machines the rule applies, then click ok then ok again.
7. You will now see your new rule. Click ok to save and exit the settings.

Share this blog post on social media:

 Managing NMP - Changing the Default PSP
for a SATP (Change from Fixed to Round
Robin EqualLogic)

The default pathing policy for a LUN can be changed (for example from Fixed to Round Robin). This
can be a LUN on an iSCSI or FC array (or FCoE for that matter).
When I refer to pathing policy I'm refering to what you may have seen if you've ever clicked manage
path's on a VMFS datastore and see it set to Fixed, Round Robin (RR) or Most Recently Used
(MRU).

In this example I will be changing the default pathing policy for an EqualLogic array from Fixed to
Round Robin.

Before I get into how to change the multi-pathing policy, it's important to understand the below 3
plugins (NMP, SATP and PSP):

 NMP (Native Multipathing Plugin) is an extensible multipathing module within ESXi. "esxcli storage
nmp" can be used to manage devices associated with NMP and to set path policies. SATPs and
PSPs are plugins within the NMP plugin.
 SATP (Storage Array Type Plugin) determines how path failover is handled for a specific storage
array.
 PSP (Path Selection Plugin) determines which physical path is used to issue an I/O request to a
storage device.

The PSP as shown below can be set manually per LUN and per ESXi server. Note the SATP is
shown and not changeable (e.g. VMW_SATP_EQL for a Dell EqualLogic iSCSI array in this case).
Of course changing it this way is a very slow and tedious process, and does not account for new
LUNs created in the future.

So we need a way to change the PSP for all the LUNs on an ESXi server and set it to default for any
new ones we create in the future. Enter "esxcli" ta-da!

With "esxcli storage nmp satp" commands we can list and set the PSP used for specific SATP's.
1. Run the following command to list all the SATP's and their default PSP

~ # esxcli storage nmp satp list

Name Default PSP Description
------------------- ------------- ------------------------------------------
VMW_SATP_EQL VMW_PSP_FIXED Supports EqualLogic arrays
VMW_SATP_MSA VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_ALUA VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_DEFAULT_AP VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_SVC VMW_PSP_FIXED Placeholder (plugin not loaded)
VMW_SATP_INV VMW_PSP_FIXED Placeholder (plugin not loaded)
VMW_SATP_EVA VMW_PSP_FIXED Placeholder (plugin not loaded)
VMW_SATP_ALUA_CX VMW_PSP_RR Placeholder (plugin not loaded)
VMW_SATP_SYMM VMW_PSP_RR Placeholder (plugin not loaded)
VMW_SATP_CX VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_LSI VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_DEFAULT_AA VMW_PSP_FIXED Supports non-specific active/active arrays
VMW_SATP_LOCAL VMW_PSP_FIXED Supports direct attached devices
~#

2. Change the default PSP for a SATP

The following command changes the default PSP for all LUNs using that SATP. So in this case all
EqualLogic LUNs will be changed to use the Round Robin PSP.

"esxcli storage nmp satp set -P=<enter PSP> -s=<enter SATP>"

~ # esxcli storage nmp satp set -P=VMW_PSP_RR -s=VMW_SATP_EQL

Default PSP for VMW_SATP_EQL is now VMW_PSP_RR
3. List the SATP's and their default PSP again, notice it has now changed
~ # esxcli storage nmp satp list
Name Default PSP Description
------------------- ------------- ------------------------------------------
VMW_SATP_EQL VMW_PSP_RR Supports EqualLogic arrays
VMW_SATP_MSA VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_ALUA VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_DEFAULT_AP VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_SVC VMW_PSP_FIXED Placeholder (plugin not loaded)
VMW_SATP_INV VMW_PSP_FIXED Placeholder (plugin not loaded)
VMW_SATP_EVA VMW_PSP_FIXED Placeholder (plugin not loaded)
VMW_SATP_ALUA_CX VMW_PSP_RR Placeholder (plugin not loaded)
VMW_SATP_SYMM VMW_PSP_RR Placeholder (plugin not loaded)
VMW_SATP_CX VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_LSI VMW_PSP_MRU Placeholder (plugin not loaded)
VMW_SATP_DEFAULT_AA VMW_PSP_FIXED Supports non-specific active/active arrays
VMW_SATP_LOCAL VMW_PSP_FIXED Supports direct attached devices
~#

4. For the change to take affect, the ESXi server must be restarted.

Ensure your host is in maintenance mode and VMs are either powered off or vMotioned to another
host before doing do.
5. Once the server has restarted if you go back to view "Manage Paths" on the LUN you will see it
has now changed to Round Robin.

6. Now you can repeat process this for all your remaining ESXi servers.

OR

Why not use power of host profiles to use this as a reference host and apply this as the default PSP
for the SATP on other hosts and monitor them for compliance in case someone changes it in the
future or rebuilds a host and forgets!
 Disk Consolidation Needed - Unable to
access file since it is locked
After deleting snapshots on a VM either by deleting an individual snapshot or selecting "Delete All"
snapshots, you may see the following warning for the VM, stating that disk consolidation is needed.

"Virtual machine disks consolidation is needed"

This can occur when a snapshot has been deleted and removed from snapshot manager, but the
consolidation of the VMDKs on disk have failed.

You can initiate a consolidation of the VMDKs manually by right clicking on the VM and
selecting Snapshot --> Consolidate.

However the consolidate operation may fail again, if the issue which caused the snapshot deletion
operation to fail disk consolidation previously has not been cleared.

It has been a good 6 months or more since I've last seen this issue, but today I found a VM with this
issue in another customers environment.

This is what had happened:

 A single snapshot had been deleted on a VM

 The disk consolidation needed warning was shown afterwards
 VM -> Snapshot -> Consolidate fails with locked file error

Initially I tried the following which can sometimes clear this:

 Shutdown guest OS and power off VM (it's not always possible to do this but I could here)
 Create a new snapshot
 "Delete All" snapshots
 vMotion to another host
 Try VM -> Snapshot -> Consolidate
But this did not clear the locked file error as shown below:

"Unable to access file since it is locked"

Keen to locate the problem I SSH'd to the ESXi server and checked the hostd.log

Even with the VM still powered off, I could see it was having a problem locking one of the VMDKs
when tying to run the Snapshot -> Consolidate task.

tail -f /var/log/hostd.log
I then ran the following command to locate which host(s) had the lock on the VMDK stated in
hostd.log

vmkfstools -D /vmfs/volumes/yourvolume/yourVM/yourlockedVM.vmdk

I could see a single entry for "RO Owner" which had the lock and the MAC address ending in "69a0".

This is the ESXi server which has the lock on the VMDK file.
Next locate which ESXi host has a network adaptor with that MAC address.

Once confirmed I placed the host in maintenance mode, DRS vMotioned all VMs to another host in
the cluster and restarted the hostd service.

/etc/init.d/hostd restart

Once the hostd service had restarted I performed a Snapshot -> Consolidate on the VM and it
completed successfully.
This issue can often occur when a virtual machine backup solution creates a lock on a VMDK and
fails to correctly release it.

In this case the snapshot which had been deleted, was left over from an automated backup
snapshot which had not been removed by the backup solution once it had completed.

Install an update/patch on ESXi Standalone

without Update Manager using esxcli

1. Use vSphere Client to connect to your ESXi host (or vCenter server)

2. Browse a VMFS datastore (e.g. the local ESXi VMFS datastore if it has one)

3. Upload your VMware ESXi update/patch (.zip file) to the VMFS datastore

4. Put your host in maintenance mode (VMs will need to be powered off or vMotioned to other hosts
if in a cluster)

5. SSH to the ESXi server and login as "root".

Note: You may need to start the SSH service (under Configuration --> Security Profile)

6. Install the update with esxcli:

esxcli software vib install --depot=/vmfs/volumes/50bf1ff8-dd8a5bd5-5fc0-00145edc9454/ESXi500-

201207001.zip
7. Reboot the ESXi server

reboot

8. Exit maintenance mode

9. Power on and/or vMotion the VMs back (if DRS is not enabled).

10. Job done!

Host currently has no management

network redundancy
When admitting a host to a HA cluster, or enabling HA on an existing cluster you may receive the
"Host currently has no management network redundancy" warning message.

This happens due to requirements in a HA cluster where the management network (that is the
service console or VMkernel port for management) is required to have two physical NICs.

If this requirement is not met the above error message is displayed. While I recommend you always,
always ensure the management network has two pNICs and is redudant (including via seperate
physical switches), it might not be possible in a demo/test environment.
In which case you may want to disable this warning message.

This can be done as follows...

1. Go to "Edit" the cluster settings

2. Click "VMware HA"

3. Click "Advanced Options"

4. Add "das.ignoreRedundantNetWarning" and set the value to "True", Click Ok
5. If there error still shows you need to select the host and click "Reconfigure for HA"

PCI standard PCI-to-PCI bridge Install Loop

- Found New Hardware Wizard after P2V
After using VMware converter to P2V a physical Windows Server 2003, I have occasionally come
across the "PCI standard PCI-to-PCI bridge" install loop.
This isnt actually an "install loop" it is prompting for the drivers for each of the 32 PCI bridges.

I havent managed to get to the bottom of it yet as it occurs only now and again, maybe its something
particular to that server and driver signing?!
However its fixable just by manually going through (Next --> Continue Anyway) 32 times to install the
driver. It will stop after 32 times, check device manager (devmgmt.msc) to confirm all drivers are
installed.

1. For each "PCI standard PCI-to-PCI bridge"

Choose Recommended and Click Next to install the driver.

2. Click "Continue Anyway" to allow installation of the device.

3. Check device manager (devmgmt.msc) to confirm all drivers are installed.
Windows 7 Black Screen / Freezes / No
Login Sceen on VMware ESX/ESXi
Right i'm going to put this down in ink, or even better electronic, as its happened twice and I forgot
what I did to fix it the first time...

Essentially the issue is a black screen (sometimes with coloured lines/dots) when booting Windows
7.

This happens before the login screen and hangs there indefintley.

This occurs after installing Windows 7 as a virtual machine on VMware ESX/ESXi and then installing
VMware Tools.
Once the Windows 7 VM is rebooted the black screen is then all you get.

The cause seems to be as soon VMware Tools is installed, and hence replaces the display driver
more video ram is required.

By default the Windows 7 VM was created with a video memory size of 4MB. This appears to be
insufficient and causes the black screen.

The fix is to increase the video memory size or change it to "Auto-detect video settings". From then
on the Windows 7 VM boots and reaches the login screen correctly as expected.
Share this blog post on social media:

Tweet

inShare
Intresting ESX Error on PCIE NIC Fail -
Dazed and confused ESX

Today I found an intresting error on an ESX server service console. The ESX 4.0 U1 server
displayed for following error...

Uhhuh. NMI received for unknown reason 21.

Do you have a strange power saving mode enabled?
Dazed and confused, but trying to continue
 The physcial server itself (a Dell PowerEdge 2950) was displaying an error on the LCD:

E171F PCIE Fatal Err Slot 3

Pressing F12 on the ESX service console to view the log displayed the following:

bnx2 Chip not in correct endian mode

bnx2 vmnic3 BUG! Tx ring full when queue awake.
WARNING: LinNet: netdev_watchdog: NETDEV WATCHDOG: vmnic3: transmit timed out

Which also confirms the cause to some VMs losing network connection due to a physcial PCI-E NIC
failure.

Even though a NIC had failed the ESX server continued to run but there were no reports of the
failure in the hardware tab or via an email from vCenter. It was only highlighted from the orange
flashing light on the physical server being noticed by a colleague.

Creating a VMkernel Port (for ISCSI,

vMotion, NFS and FT) on Standard and
Distrubuted vSwitches
A VMkernel port is required on each ESX server where the following services will be used:

 vMotion
 iSCSI
 NFS
 Fault Tolerance

Without a VMkernel port none of these services can be used on the ESX server.
This is a prequisite before Configuring iSCSI Storage (Basic) or Configuring iSCSI Storage
(Advanced with CHAP) and Creating a VMFS Datastore.

This is how to create and configure a VMkernel port on an ESX server using a standard vSwitch (the
process is the same on a distributed vSwitch - its just under the DVS view in the same section).

This assumes you already have a vSwitch (standard or distributed) with pNICs and appropriate
connections the the physical network.

1. Connect to the ESX server with vSphere client.

2. On a specific host, navigate to the "Networking" section within the "Configuration" tab .

3. On the desired vSwitch (with pNICs and appropriate connections the the physical network), Click
"Properties".

4. In the vSwitch properties in the "Ports" tab, Click "Add..."

5. Choose "VMkernel" for the connection type, Click Next.
6. Give the VMKernel port a label (e.g. iSCSI - if it will purley be used for iSCSI).

Enter the VLAN ID if the pNICs connected to the vSwitch are trunk ports and you have a specific
VLAN for this traffic (e.g. a dedicated storage VLAN).

Now if the port will only be used for storage services (iSCSI and NFS), Click Next.

If the port will be used for all VMkernel services (iSCSI, NFS, vMotion and FT), tick the additional
boxes to allow this port to be used also for those services, Click Next.
7. Enter an IP address to assign to the VMkernel port (this is in addition to the service console).
Typically the VMkernel and service console networks are on different subnets (seperated using
VLANs)

Enter a subnet mask.

Enter a default gateway for VMkernel traffic.

Click Next.
8. Review the settings for the VMkernel port. Click Finish to create the port.
9. The port is created and visible within the vSwitch properties. They can be edited here if required.

Click Close.
10. The VMkernel port is now visble in the networking view of the ESX server "Configuration" tab
along with its IP address.
Now the VMKernel port has been created iSCSI can now be used. This is a
prequisite before Configuring iSCSI Storage (Basic) or Configuring iSCSI Storage (Advanced with
CHAP) and Creating a VMFS Datastore (on SANs).

Guest OS Slow, Freezing or Hanging with

Windows Server 2008 R2 or Windows 7

There is an issue with a Guest OS of either Windows Server 2008 R2 or Windows 7 running on
VMware ESX/ESXi 4.x with VMware Tools installed. The display driver SVGA-II freezes
intermittently and sometimes permanently requiring reset of the VM.

This is a display driver issue which is resolved in the latest VMware Tools in ESX/ESXi 4.0 Update
1.
However manual intervention is also required after updating to the latest VMware Tools to
replace the display driver.
Check the current version of VMware Tools and display driver being used.
VMware Tools 4.0.0 Build 208167 or before uses the "VMware SVGA-II" display driver which causes
the problem.

1. Uninstall VMware Tools

2. Restart the server.

3. Install latest VMware Tools 4.0.0 Build 219382 or later

This will use the "Standard VGA Graphics Driver" but the video will appear slow and choppy.

To resolve this the VMware SVGA 3D (WDDM) for Windows Server 2008 R2 and Windows 7 needs
adding.

4. Manually update the display driver via Device Manager to the following driver:
C:\Program Files\Common Files\VMware\Drivers\wddm_video
"VMware SVGA 3D (Microsoft Corporation - WDDM)" The driver folder is created when the latest
version of VMware Tools was installed.

5. Restart the server.

ESXi - Accessing the Unsupported Console
As some may know ESXi 3.5 and 4.0 has an unsupported console which can be accessed for
VMware technical support etc.

However if you know what your doing it can be useful for getting to the bottom of a problem before
calling VMware about an issue.

To gain access to the Unsupported Console:

1. ALT+F1
2. Type "unsupported"
3. Type <your root password>

And there you are, so blindingly obvious its unsupported! So use with caution. It runs a very light
version of Linux called Busybox.

You will find an array of esxcfg commands available to assist if required.

Permissions, Users and Roles on ESX

If you are not using vCenter or only want to give a specific person access to an ESX server to do a
specific task then here is how to do it...

First connect to the ESX server with VI client (it will need to have full admin right e.g. root).

If you want the user to only do certain tasks then we first need to create a role.

The roles can be found under the "Administration" button and the "Roles" tab.

To add a new role, right click and select "Add..."

Give the role a name (in this case "VM Admin" because it will have all permissions to the VMs).
Select the permissions and click "Ok".
Now you can see your new role with the default roles.

Next is to create a user that can carry our this role.

Click on the ESX server in the inventory and navigate to the "User & Groups" tab.
Right click in the users list and select "Add..."

Give the user a name (e.g. bob) and a password. Click "Ok".
The user will now appear in the list of users.

The next step is to give the user a role. This is done under the "Permissions" tab.

Right click in the permissions list and select "Add Permission...".

Notice the vpxuser in the list below, this is because this ESX server I am doing this on is connected
to a vCenter server. The "vpxuser" is created and given the Administrator role when you connect the
ESX server to vCenter.
Add the user "bob" and assign a role (e.g. VM Admin that we created).

Choose to propogate the permissions to child objects.

Click "Ok".
The new permission can now be seen in the list of permissions, and is effective immediatley.

Virtual Machine Automatic Startup and

Shutdown
It is possible to set virtual machines to automatically startup and shutdown with the ESX server.

You may want to do this for example in a test environment where vCenter is in a VM.

Rather than connecting to the ESX server and starting the vCenter VM then connecting to vCenter,
you could connect straight to vCenter.

Click on the "Configuration" tab of the ESX server and go to the "Virtual Machine Startup/Shutdown"
section.

You will see the VMs are set to manual startup.

Click on "Properties".

Check the box to "Allow virtual machines to start and stop automatically with the system".
Set the default startup and shutdown delay.

If VMware tools is installed you can set the guest to shutdown gracefully rather than just powering
off.

Select the VM you want to auto start/stop and click "Move Up" so that it goes to "Automatic Startup".

Click Ok.
An overview of the configuration can now been seen in the "Virtual Machine Startup/Shutdown"
section.

Soft and Hard Stopping an Unresponsive

VM
Sometimes a virtual machine can stop working and fail to respond. While you may not be able to
power off the VM gracefully via VI client to vCenter or ESX there is another way to do this, ensuring
it is powered off properly. If you kill off the process the VM is running under you may stop it from
working again. You can use the vmware-cmd command in the service console to stop the VM.
Logon to the ESX Server that is running the VM.

List all VMs on that ESX Server (Check you VM is listed here):
vmware-cmd -l

Get the current state of the VM:

vmware-cmd /path/to/vm getstate

If an answer is needed run:

vmware-cmd /path/to/vm answer

Try to soft stop the VM:

vmware-cmd /path/to/vm stop trysoft

Failing that try to hard stop the VM:

vmware-cmd /path/to/vm stop hard

Failing that kill the master user world id (vmid):

cat /proc/vmware/vm/*/names | grep myvm1

less /proc/vmware/vm/ value/cpu/status

/usr/lib/vmware/bin/vmkload_app -k 9 vmid#

Failing that crash the VM and get the logs (run in a directory with some space to spare):
vm-support -x
vm-support -X vmid#

Service Console - Virtual Switch

Commands
If you need to change your vswitch and port group settings using the service console, esxcfg-vswitch
is what you need to use.
If you were "tweaking" ESX network settings via VI Client and lost connectivity you will find these
commands very useful.

List all virtual switches and the port group information:

esxcfg-vswitch -l

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 64 9 64 1500 vmnic2,vmnic0
PortGroup Name VLAN ID Used Ports Uplinks
Server Network 41 5 vmnic0,vmnic2
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch1 64 6 64 1500 vmnic3,vmnic1
PortGroup Name VLAN ID Used Ports Uplinks
Service Console 35 1 vmnic1,vmnic3
VMkernel 35 1 vmnic1,vmnic3
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch2 64 1 64 1500
PortGroup Name VLAN ID Used Ports Uplinks
Internal 0 0

Delete a port group from a vswitch:

/usr/sbin/esxcfg-vswitch -D "Service Console" vSwitch1

Add a port group to a vswitch:

/usr/sbin/esxcfg-vswitch -A "Service Console" vSwitch1

Set the VLAN ID of a port group:

/usr/sbin/esxcfg-vswitch -p "Service Console" -v35 vSwitch1

Check if virtual switch already exists:

esxcfg-vswitch -c vSwitch2

Create a virtual switch:

esxcfg-vswitch -a vSwitch2

Check if a port group on a virtual switch already exists:

esxcfg-vswitch -C VMotion

Create a port group on a virtual switch:

esxcfg-vswitch -A VMotion vSwitch2

Link a virtual switch to a physical nic:

esxcfg-vswitch -L vmnic2 vSwitch2

Service Console - Setting the VMkernel

Default Gateway
To see the default gateway of VMKernel:
esxcfg-route

To set the default gateway of VMKernel:

esxcfg-route 192.168.1.1
Service Console - VMFS Datastores
Create a VMFS volume on a LUN:
vmkfstools -C vmfs3 -S label vmhba1:0:2:1

Identify disks attached to the ESX server including SAN LUNs (in human readable format):
vdf -h

Read Metadata from VMFS volumes (version, capacity and file block size):
vmkfstools -P /vmfs/volumes/LUN-A1

Add and extent to a datastore (Each LUN can be max 2TB. 32 extents can be added to reach
64TB):
[vmkfstools -Z addthislun tothislun]
vmkfstools -Z vmhba1:0:12:1 vmhba1:0:11:1

Delete an extended volume:

vmkfstools -C vmfs3 -S LUNB vmhba1:0:12:1

Rename a VMFS datastore:

ls -laF /vmfs/volumes/
Note down the id of the volume linked to the datastore you want to rename (e.g.
/vmfs/volumes/477c7-634968-3c1a-001...).
rm -rf /vmfs/volumes/oldname

ln -s /vmfs/volumes/477c7-634968-3c1a-001... /vmfs/volumes/newname

Service Console - ESX Server Firewall

Commands
The firewall built into ESX server uses iptables, the very commonly used Linux firewall. However to
create the rules another esxcfg tool is used, which is esxcfg-firewall.

To list the services currently controlled by the firewall:

esxcfg-firewall -s

To list the firewall rules:

esxcfg-firewall -q [servicename]
esxcfg-firewall -q
Enable a service:
esxcfg-firewall -e [servicename]
esxcfg-firewall -e sshClient

Disable a service:
esxcfg-firewall -d [servicename]
esxcfg-firewall -d sshClient

Open a port:
esxcfg-firewall -o 465,tcp,out,out-smtps

Close a port:
esxcfg-firewall -c 465,tcp,out

Using PowerCLI to get the IP address of a

VM
Here is a simple but handy PowerCLI one liner which can output the VM name and it's IP address.

Connect-VIServer localhost
Get-VM | Select Name, @{N="IP Address";E={@($_.guest.IPAddress[0])}}

Name IP Address
---- ----------
ABWEB1v 172.16.100.1
ABWEB2v 172.16.100.2
ABWEB3v 172.16.100.3
ABWEB4v 172.16.100.4
ABWEB5v 172.16.100.5
ABWEB6v 172.16.100.6
ABWEB7v 172.16.100.7
ABWEB8v 172.16.100.8
ABWEB9v 172.16.100.9
ABWEB10v 172.16.100.10
ABWEB11v 172.16.100.11
ABAPP1v 172.16.101.20
ABDOM1v 172.16.102.20

Getting a little more complicated here we are getting all the VMs in any cluster starting with "Web-
Cluster-" and then returning the VM Name, ESXi host and IP address:

Get-Cluster "Web-Cluster-*" | Get-VM | Select Name, Host, @{N="IP

Address";E={@($_.guest.IPAddress[0])}}

Due to the way the IP address is referenced and a VM can have more than one IP, you can list
additional IPs by adding or changing the array pointer from 0 to 1 and so on, in this part of the
command "$_.guest.IPAddress[1]"

View, Start and Stop Remote Tech Support

Mode (TSM-SSH) on All ESXi Servers -
PowerCLI Get-VMHostService
Ive started using PowerCLI a bit more in day-to-day situations, and i'm finding it rather useful. Once youve
got your head round the syntax and the available cmd-lets its a viable time saving option, especially as
you grow your little repo of reusable scripts. Here is one of mine that I made today...
I had the need to enable "Remote Tech Support Mode" (TSM-SSH) on all ESXi 4.1 servers for various
reasons then disable it again.
Not favouring the manual process of going into each host in vCenter --> Host --> Configuration -->
Security profile etc etc I wanted to be able to run a script that would do this for me. And confirm
afterwards I had turned it all back off.
That resulted in the following 3 PowerCLI scripts for viewing, starting and stopping the TSM-SSH service
on all ESXi servers.

Note: Before running remember to run "Connect-VIServer vcenter.domain.local"

ViewServiceSSH.ps1
function ViewServiceSSH {
$VMHost = Get-VMHost
foreach ($VMHost in $VMHost) {
Get-VMHostService -VMHost $VMHost | where {$_.Key -eq "TSM-SSH"} | Select
@{N="VMHost";E={$VMHost.Name}},Key,Running
}
}
ViewServiceSSH

Example Output:

StartServiceSSH.ps1
function StartServiceSSH {
$VMHost = Get-VMHost
foreach ($VMHost in $VMHost) {
Get-VMHostService -VMHost $VMHost | where {$_.Key -eq "TSM-SSH"} | Start-VMHostService
}
}
StartServiceSSH

StopServiceSSH.ps1
function StopServiceSSH {
$VMHost = Get-VMHost
foreach ($VMHost in $VMHost) {
Get-VMHostService -VMHost $VMHost | where {$_.Key -eq "TSM-SSH"} | Stop-VMHostService
}
}
StopServiceSSH

Using a CSV file to provision multiple VMs

from a template
With the vSphere PowerCLI its possible to deploy multiple virtual machines from templates defined in a
CSV file.
The CSV file needs contain the following column headings exactly for the below script to work.

Name
Template
DestinationHost
CustomSpec
NumCpu
MemoryMB
You will need an existing template you have created prior and also a guest OS customisation
specification.

Connect-VIServer vcenter1.vmadmin.co.uk

$VirtualMachinesCSV = "C:\VMsFromTemplate.csv"
$strDescription = "Created from template and CSV by Andy Barnes"

$VirtualMachinesDetails = Import-CSV $VirtualMachinesCSV

$VirtualMachinesDetails | %{ New-VM -Name $_.Name -Template $(Get-Template $_.Template) -
VMHost $(Get-VMHost $_.DestinationHost) -OSCustomizationSpec $(Get-OSCustomizationSpec
$_.CustomSpec) }
$VirtualMachinesDetails | %{ Set-VM -VM $_.Name -NumCpu $_.NumCpu -MemoryMB $_.MemoryMB -
Description $strDescription -Confirm:$false }
$VirtualMachinesDetails | %{ Start-VM -VM $_.Name -Confirm:$false }

Rescan All ESXi Server HBAs - PowerCLI

So you've just created an additional LUN/volume and presented it to all your ESXi servers?

Now you want to rescan the HBAs on the servers so you can start using the storage, but you dont
fancy manually doing this on say 10 or maybe even 100 servers.

Here is a very handy piece of VMware PowerCLI that will connect to your vCenter Server, get the list
of clusters and hosts, then rescan all the HBAs on those hosts (ESX/ESXi).

Connect-VIServer vcenter.domain.local
Get-Cluster | Get-VMHost | Get-VMHostStorage -RescanAllHBA

Note: Don't forget to change vcenter.domain.local to your vCenter server!!

PowerCLI - List All ESXi Hosts Network Info

(and Output to CSV)

Before performing a piece of network maintenance I wanted ensure I had an up-to-date list of
network information for all ESXi servers.

I was apprehensive to refer to old documentation incase something had changed.

To do this I used PowerCLI, specifically "Get-VMHostNetworkAdaptor" to retrieve a current set of

information from all VM hosts containing networking information.

List VM host network details and output to the PowerCLI console:

Get-VMHostNetworkAdapter | select VMhost, Name, IP, SubnetMask, Mac, PortGroupName,

vMotionEnabled, mtu, FullDuplex, BitRatePerSec

Output to CSV VM host network details:

Get-VMHostNetworkAdapter | select VMhost, Name, IP, SubnetMask, Mac, PortGroupName,

vMotionEnabled, mtu, FullDuplex, BitRatePerSec | Export-Csv C:\VMHostNetworkDetails.csv
Example CSV Output: