Pages

Wednesday, December 24, 2014

Those who have recently upgraded to vSphere 5.5 may have noticed that if you’ve also gone ahead and upgraded the virtual machine’s hardware to version 10 would result in the inability to edit the virtual machine’s settings via the vSphere Client because you are now forced to use the vSphere Web Client as the following message indicates:

You cannot use the vSphere Client to edit the settings of virtual machines of version 10 or higher.

Use the vSphere Web Client to edit the settings of this virtual machine.

Most administrators at this point can proceed by logging onto the vSphere Web Client to edit the settings but what if vCenter was down? Connecting directly to the host wouldn’t allow you to edit the settings either. The workaround to this is to actually update the client to vSphere Client 5.5 Update 2 which would result in the following message when you attempt to edit a virtual machine’s settings:

You are about to edit a virtual machine of version 10 or higher. Only version 8 features will be available for Edit using this client.

If you want to edit the advanced hardware features of this virtual machine, please use the vSphere Web Client to login to vCenter.

Various advanced properties won’t be available but actions such as extending a hard disk is allowed.

There has been times where I’ve found myself stuck in a datacenter without access to the internet which therefore means upgrading the vSphere Client to 5.5 Update 2 would not be possible. The workaround to this is to use the command line via SSH or console to extend the disk and the following outline the steps to do this.

Step #1 – Check for Snapshots

The first step for this process is to ensure that there are no snapshots created on the VM that you are attempting to extend the VMDK. There are plenty of ways to determine whether there are snapshots such as browsing into the directory of the virtual machine and looking for -delta.vmdk files as shown in the following screenshot where ls was executed before and after a snapshot was created:

Another method which I favour in using is to use the vim-cmd command to list snapshot information for the virtual machine. The reason why I favour the vim-cmd command is because it is available via the ESXi’s console with no reliance on PowerCLI which requires vCenter to be up and if vCenter was up, you could just use the Web Client to increase the disk size.

Begin by SSH or accessing the console of the ESXi server that the VM is hosted on and execute the following command to list the VMs:

vim-cmd vmsvc/getallvms | more

The VM we’re interested in is the -FS-01 server:

Note the VMID # on the left which in this case is 21.

With the VMID obtained, proceed by executing the following command to list the snapshots:

vim-cmd vmsvc/snapshot.get [VMID]

For this example, we’ll execute the following:

vim-cmd vmsvc/snapshot.get 21

Note that there is a snapshot named Snappy for this VM.

To remove all snapshots on this VM, continue by executing the following command:

vim-cmd vmsvc/snapshot.removeall [VMID]

For this example, we’ll execute the following:

vim-cmd vmsvc/snapshot.removeall 21

You can verify that the snapshots are gone by executing:

vim-cmd vmsvc/snapshot.get 21

… again.

Step #2 – Expand VMDK with VMKFSTOOLS

Before I begin, note that expanding a disk with vmkfstools requires the VM be powered off and I am unable to find a way to expand the disk while the VM is powered on even though the vSphere Client allows it so when I do, I’ll update this post. To shutdown the VM, execute the following command:

vim-cmd vmsvc/power.shutdown vmid

For this example, we’ll execute the following:

vim-cmd vmsvc/power.shutdown 21

With the VM powered down, continue by browsing to the directory of the VM and execute:

du -ah

… to list all the files and the size:

The disk we’re going to expand for this example is named -FS-01_3.vmdk which is currently at 1.0G. The command we’ll use to expand the disk is:

vmkfstools -X <sizeOfVMDK>GB <diskname>.vmdk

… where we’ll need to define the size of the VMDK and the VMDK file name. Note that the size defined here is the total size so the final size of the VMDK would be so if we use 9GB, it would expand the VMDK to the size of 9GB and not 9 + 1 = 10GB. Also, the VMDK filename we’ll be using is the FS-01_3.vmdk and NOT the FS-01_3-flat.vmdk file even though that file has a size associated to it.

Sunday, December 14, 2014

I don’t usually perform upgrades of Nutanix blocks from 5.1 to 5.5 but I’ve noticed that whenever I do, I’ve always had to reference an email in my Outlook’s Draft folder with the notes and screenshots I’ve captured during a previous upgrade so just in case I needed to reference it in the future, I’m going to go ahead and get a post written on my blog.

The configuration I’ll be upgrading in this example consists of an older Nutanix 2000 series block with 2 blades and a newer Nutanix 7000 series block with one blade running ESXi 5.1.0 build 1065491:

This upgrade was performed a while ago so the version we’ll be upgrading to is VMware ESXi 5.5 build 1331820.

Step #1 – Download Upgrade Package

I find that one of the questions I get asked most from colleagues and clients are that they cannot find the the upgrade package by navigating through VMware’s download section. The reason for this is usually because they are navigating to an update of version 5.5.0 with the path such as:

Home –> All Downloads –> VMware vSphere –> VMware ESXi 5.5.0 Update 1

The section above provides the following options:

ESXi 5.5 Update 1 Driver Rollup 2 (includes VMware Tools)

ESXi 5.5 Update 1 Driver Rollup 2 README

ESXi 5.5 Update 1 ISO image (includes VMware Tools)

ESXi 5.5 Update 1 Offline Bundle

None of the above can actually be used to upgrade our blades from ESXi 5.1 to 5.5 because the ESXi 5.5 Update 1 Offline Bundle is only used for updating 5.5.0 to 5.5.0 U1. Downloading the first package on the list would provide you with ISOs for installing ESXi 5.5U1 on a new blade. As an example, here’s what the contents of the VMware-ESXi-5.5U1-Rollup_2ISO.iso contain:

The correct page that you’re looking for is to select the RTM version of 5.5.0 as such:

Here is where you will find the ESXi Offline Bundle:

The upgrade package should be in the form of a zip package that ends with -depot.zip:

The output of the upgrade should look something similar to the following:

The output from the SSH session should display the following for each successfully upgraded blade in the cluster:

Installation Result

Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.

Reboot Required: true

Step #4 (Optional) – Upgrading individual blades

If there is any issue with upgrading a specific blade in the cluster via the command ran in the CVM or if you would like to upgrade one blade to test, it is possible to simply SSH directly to the ESXi host and use the regular esxcli command to upgrade the host as such:

While there could be various reasons why this error would be thrown, one of the users is if the rapport service account password has expired and requires a new password to be set. To determine this, launch the Computer Management console on the Wyse Device Manager server and navigate to the Local Users and Groups –> Users node, then open the rapport service account properties:

Notice that the User must change password at next login is checked which means the password has expired and must be changed. Proceed by unchecking the checkbox and check the Password never expires checkbox:

Run Test Connection again for the Software Repository to ensure that the test completes successfully:

Tuesday, December 9, 2014

I recently had to work with a Microsoft support engineer to troubleshoot an Active Directory Certificate Services issue and managed to write down a few commands he used during the troubleshooting process and thought I’d write a blog post so I can refer to them in the future since I’m bound to forget.

Command to collect CA information CRL:

Before starting the troubleshooting, the engineer ran the following commands to collect base information.

The following certutil command lists the Enterprise Root or Subordinate CAs found in Active Directory:

C:\>certutil

Entry 0:

Name: `test'

Organizational Unit: `'

Organization: `'

Locality: `'

State: `'

Country/region: `'

Config: `conspschsrv.contoso\test'

Exchange Certificate: `'

Signature Certificate: `'

Description: `'

Server: `conspschsrv.contoso'

Authority: `test'

Sanitized Name: `test'

Short Name: `test'

Sanitized Short Name: `test'

Flags: `1'

Web Enrollment Servers: `'

Entry 1:

Name: `CONTOSO ROOT CA'

Organizational Unit: `'

Organization: `'

Locality: `'

State: `'

Country/region: `'

Config: `conCERTSRV.contoso\Contoso ROOT CA'

Exchange Certificate: `'

Signature Certificate: `'

Description: `'

Server: `conCERTSRV.contoso'

Authority: `CONTOSO ROOT CA'

Sanitized Name: `CONTOSO ROOT CA'

Short Name: `CONTOSO ROOT CA'

Sanitized Short Name: `CONTOSO ROOT CA'

Flags: `1'

Web Enrollment Servers: `'

Entry 2: (Local)

Name: `CONTOSO-Sub-CA'

Organizational Unit: `'

Organization: `'

Locality: `'

State: `'

Country/region: `'

Config: `conSCASRV01.contoso\CONTOSO-Sub-CA'

Exchange Certificate: `'

Signature Certificate: `conSCASRV01.contoso_CONTOSO-Sub-CA.crt'

Description: `'

Server: `conSCASRV01.contoso'

Authority: `CONTOSO-Sub-CA'

Sanitized Name: `CONTOSO-Sub-CA'

Short Name: `CONTOSO-Sub-CA'

Sanitized Short Name: `CONTOSO-Sub-CA'

Flags: `13'

Web Enrollment Servers: `'

CertUtil: -dump command completed successfully.

Note that the above output shows that there are currently 3 Enterprise CAs that is found in Active Directory.

The support engineer suspected that there was something wrong with the published CRL so the following command was executed to check the start and end validity date of the file (I’ve highlighted this information in red:

Updating the CRL file for http access is simply copying the CRL file from the Root CA’s C:\Windows\System32\certsrv\CertEnroll folder to the same folder on the Subordinate CA but to update the one published through LDAP, the command certuitl -dspublish <Your-Root-CA>.crl <YourSubOrdinateCAServerName is ran on the subordinate CA: