Fix: Cisco UCSM – Default Keyring’s certificate is invalid

Recently during some prep work for a UCS firmware upgrade I noticed that there was a major alert showing for keyring certificate being invalid. At first I was a bit concerned but since it didn’t affect my login to UCS Manager I assumed it wasn’t too serious. After a bit of searching around the internet I found from Cisco’s site the CLI Configuration Guide for UCS (page 6) which shows the quick and easy fix to the problem.

planning-fault check major

Open an SSH session to the IP address/hostname of UCS Manager. It will connect to the primary Fabric Interconnect. Enter the commands in the order of steps below:

Step 1 UCS-A# scope security

Step 2 UCS-A /security # scope keyring default

Step 3 UCS-A /security/keyring # set regenerate yes

Step 4 UCS-A /security/keyring # commit-buffer

After the commit-buffer command has been issues all GUI sessions will be disconnected and you will need to log in again. When you log in next time you’ll be prompted to accept the new certificate. Once accepted UCSM will open and the alert will now be gone.

All fairly quick and painless!

Fix: VMware 5.5 Importing VMDK to VM – Failed to open disk scsi0:0

I’m currently assisting on a project for Big Data which requires some VMDKs to be imported and added to existing VMs. I really don’t understand why the vendor doesn’t supply an appliance to import rather than having to build out multiple nodes from a VMDK file. The only redeeming factor among all this is that it’s only a proof of concept but my concerns have been raised about a proper production deployment. A request was made to add the VMDK supplied to 4 existing VMs which were essentially just shells waiting for disk to be assigned/attached. I copied the VMDK into the folder of one of the VMs, attached the disk to the VM and when I went to power it on I got the following error:

Failed to open disk scsi0:0: Unsupported or invalid disk type 7. Ensure the disk has been imported

2015-03-03_16h49_17

The VMDK was obviously from a different version of vSphere and required the disk to be re-imported and also configured to zeroedthick. The steps followed to resolve this issue were:

  1. Enable SSH access to ESXi host via the Security Profile under Configuration.
  2. Open a putty SSH session to the ESXi host
  3. Change directory to the folder of the VM: cd /vmfs/volumes/<datastore>/<VM_folder>
  4. Run the vmkfstools utility to clone the VMDK as zeroedthick: vmkfstools -i imported_disk.vmdk -d zeroedthick new_clone.vmdk
  5. Go to the datastore the VM resides on in vSphere and right-click the imported_disk.VMDK and select Delete from Disk
  6. Edit the settings of the VM and connect the new_clone.VMDK
  7. Power on the VM and the error is now gone
  8. Close the putty session and disable SSH access to ESXi host