updateupgradeesxcli

VMware ESXi Upgrades and Updates with ESXCLI

This post details the steps to upgrade ESXi where VUM is not available or direct access to the hosts is difficult e.g remote office/datacentre.

Requirements:

  • Root or similar access to the host (can be via the VMA)
  • Offline bundle of the ESXi image (.zip format)
  • Putty or similar to access the shell
  • Host should be in maintenance mode
  • HA should be disabled on cluster

Start the ESXi Shell and SSH services, select the host –> Configuration –> Security Profile –>Properties –> ESXi Shell –> Options –> Start

Repeat for the SSH Service

start-ssh

Open a shared or local datastore on the applicable host, select the host –> Configuration –> Storage, right-click on the applicable datastore and select Browse Datastore.

browse-datastore

Select the Upload Files to this Datastore button, select Upload File and browse to and select the .ZIP of the ESXi offline bundle to upload.

upload-zip

Run an SSH client e.g putty to SSH to the shell of the host.

Find Image Profiles

Find the available image profiles within the offline bundle by running the esxcli command:

esxcli software sources profile list -d /vmfs/volumes/<volume>/<ZIPFILE>.zip

*esxcli is case sensitive and paths can be tab completed*

Validate Image Profile

Validate current profile against new image profile use the command:

esxcli software profile validate -d /vmfs/volumes/<volume>/<ZIPFILE>.zip -p <profile>

You should see:

Profile Validation Result
Compliance: True

If the validation result returns false, you can still proceed with the update or upgrade if you confirm the invalid vib is not applicable.

Update

An update will replace existing vibs with new vibs and include vibs that are not currently on the installed image profile.

esxcli software profile update -d /vmfs/volumes/<volume>/<ZIPFILE>.zip -p <profile>

*use -f to force the update, will be required for a false validation of the image profile*

Upgrade

An upgrade replaces the current image profile with the image profile specified in the command. All vibs including manual additions to the current installed image profile may be removed. If there are custom vendor vibs, either use the Update option or manually apply the custom vibs after the upgrade.

esxcli software profile install -d /vmfs/volumes/<volume>/<ZIPFILE>.zip -p <profile>

*if the upgrade fails due to custom vibs, you can use the parameter –ok-to-remove at the end of the command*

 

Once the update or upgrade is complete, type the command reboot

SCCM Site Code Change with PowerShell

I came across a case whereby a test SCCM installation had been completed and needed to be removed and replaced with a production instance. There are a few cleanup operations but in this case I needed to automate a way to change the clients to point to the new Site Code.

This can be completed with the below PowerShell command replacing SITECODE with the new Site Code (PowerShell run as administrator)

Running across VM’s in vCenter

I also have a script for completing in PowerCLI by using the Get-VM command, this is broken down below.

This presumes you have already created a connection to your vCenter through PowerCLI

*Use PowerCLI x86

Note that there is no error checking on the below, replace the GuestUser and GuestPassword parameters with your own credentials with administrative rights on the VM Guest OS.

In the perfect world this environment would have WinRM enabled across the server estate but alas it didn’t. This saved a fair amount of manual work for me and I hope it does you too!

Complete script available here –> SCCMSiteCodeChange just paste into PowerShell ISE, save and run from PowerCLI.

WD NAS as VMware NFS Datastore

I came across a use case for using a Western Digital MyBook Live as a VMware NFS datastore, I’m fairly sure this can be completed on similar devices with a bit of configuration.

This initial task is to access the shell of the WD MyBook, this can be completed by accessing the ip or hostname of the device through the web url as documented here, below is a quick reference.

  1. Login to the URL of WD MyBook http://ipaddress, if address is unknown, try using DHCP to find a reservation
  2. Change the URL to http://ipaddress/UI/ssh
  3. Tick active SSH

Next you will need to create an SSH session to the IP address of the WD MyBook in this case I am using putty, the default credentials are below:

username: root 

password: welc0me

We then need to create the NFS share and configure the permissions for the share (thanks to Falco Timme).

  1. Type su and hit enter to raise the rights to sudo “admin”
  2. Type the command mkdir /nfs/sharename/ where sharename is the name of your share.
  3. Enter vi editor to edit the exports file with the command vi /etc/exports (This is to configure the share permissions)
  4. Edit the file as shown below replacing the 192.168.X.X with the IP of the ESXi host (deleting the other lines from the file will stop the web interface from working), i for insert (use the arrow keys to navigate, :wq! to save and exit, :q! to exit without saving. Excellent Vi Editor tut here. *Add additional entries for extra hosts*2015-09-14_23-41-53
  5. Type the command exportfs -a hit enter and type reboot, hit enter to complete.

We now need to map the NFS drive in ESXi as below:

Via VI Client

  1. Open a vi client to the ESXi host and select the Configuration tab
  2. Select Storage on the left and Add Storage on the right
  3. Select the option Network File System and click Next
  4. Enter Server hostname or IP, folder as /nfs/sharename and give the datastore a name, click Next2015-09-16_22-49-54
  5. Select Finish to complete

Via ESXi Shell

  1. Create putty session to ESXi Host
  2. Enter the command esxcli storage nfs add -H hostnameorIP -s /nfs/sharename -v datastorename and hit enter.2015-09-16_23-10-12

I will be attempting the same with a Buffalo Link station in the coming weeks but its food for thought in terms of a reuse for cheap ESXi NFS Storage!

VMware vCenter SRM 5.5 Database Configuration

I was repairing an issue with connectivity between a primary vCenter and secondary vCenter site and their SRM Servers when I came across a configuration on both SRM databases which was not ideal. Both SRM users had sysadmin rights on each SQL Server.

I have seen many installations whereby the privilege of sysadmin has been given to a SQL Security login account, this being the case in this instance. Best practices for a secure environment is to limit this activity as much as possible.

According to the installation documentation the database schema must have the same name as the database user account among other things.

Database schema:

  • The Site Recovery Manager database schema must have the same name as the database user
    account.
  • The Site Recovery Manager database user must be the owner of the Site Recovery Manager
    database schema.
  • The Site Recovery Manager database schema must be the default schema for the
    Site Recovery Manager database user.

I would advise making individual AD accounts during the installation of SRM, the procedure below outlines the database configuration. (Thanks to our DBA for the assistance).

Create your security account as you normally would do, e.g DOMAINNAME\SRMSERVICE

Ensure that the service VMware vCenter Site Recovery Manager Service on the SRM servers are also running as the DOMAINNAME\SRMSERVICE user. I have noticed this gets set back to local system if you run the modify wizard on an existing installation.

2015-09-14_22-20-44

Ensure Default Database is set to the SRM Database. Select the SRM Database and select

New Query and type the below command, click execute.

2015-09-14_22-33-13

This maps the security login DOMAINSERVICE\SRMSERVICE to the dbo database user account, as seen if you open the SRM database user account “dbo”.

2015-09-14_22-36-10

Complete the same on both the SRM primary and secondary databases and on each primary and secondary SRM server restart the VMware vCenter Site Recovery Manager Service.

 

 

VMware vShield Driver Installation through PowerCLI

While deploying vShield I have found the easiest way to automate the installation of the additional vShield Driver (Now called Guest Introspection Driver) is to use PowerCLI and complete through the invoke-vmscript command.

I will presume that you have PowerCLI installed, else it can be obtained from VMware.com.

*If using an x64 OS you will need to use the x86 version of PowerCLI*

Connect to your vCenter Server where *vCenterServer* is the name of your vCenter Server, I use the $Credential variable to store the credential for this session but you can skip that and use the -user and -password parameters after the connect-viserver if preferred;

The $Name variable stores the name that is input when the script is run, if you specify a wildcard * for the name this will run against all servers so be warned! In turn you can run against VM1 and VM2 with VM*.

The name is then checked using the Get-VM command to see if the server exists displaying “VM FOUND 🙂” if true or “VM NOT FOUND 🙁” if false. Until the correct name is entered the script will keep prompting for a name.

The below code is only required if the hostname differs from the name of the VM.

Next we attempt to mount the VM tools to the VM

Get the drive letter of the VM and store in the $DriveLetter variable (I have seen this fail if the VM has WMI issues).

Storing the entire script in $ScriptText to run in the Invoke-VMScript command, replace Administrator and *Password* with your local admin account credentials.

Entire Script available below with additional menu option, split into Functions as I attempt to learn Powershell!
I apologise to any programmers/script writers as my script writing has a lot to be improved.

vShieldDriverInstall