esxi

Vmware Esxtop Displaying Incorrectly In ESXi 5.5 Over SSH From Linux

/ Christopher Paquin

Clip-art-top-cat-796078So I ran into this odd issue last night working in the old homelab. I was working on troubleshooting an issue with datastore performance on one of my Supermicro ESXi servers. I have two and they are awesome beasts that have been migrated into fancy Cooler Master cases, however that is a tale for another day. Anyway, I digress… the datastore. So yeah, it's a local raid 5 datastore attached to an LSI 9260-8i controller. This particular datastore is 3 600gb 15k SAS drives, and for some reason its slow as all get-out.

So being the command line guy that I am, I ssh from my Linux (Fedora 19, specifically) into my troublesome ESXi server and attempt to run esxtop to see if I can get a read on the disks. Much to my chagrin, the output of esxtop is a garble of text Unreadable to say the least.

 

Esxtopmacdefault_thumb[1]

an example of the horror i saw that night

 

Turns out that this is an issue related to terminal emulation type. Thanks to this bro, who ran into same issue on his Mac, I was able to get back in the game and determine that yes, you should not configure raid 5 with a dead BBU. Anyway, while his fix was not exactly help for me, it let me know what I needed to do to fix this issue.

The gist of the issue is this. In Linux (Fedora at the very least) the default terminal emulation type is xterm-256color. Set your terminal type to this, ssh to and ESXi 5.5 box, and experience this formatting debacle for your self.

Thankfully the fix is simple, just change your terminal emulation type to "xterm" and you will be good to go. I accomplished this with the command below.

# export TERM=xterm

 

I can tell you this, I never had issues ssh'ing to ESXi 5.0 from Linux, so this was probably introduced in ESXi 5.5

 

Related articles

HomeLab: Basic Syslog Configuration on Cisco Catalyst Devices
HomeLab: Upgrading Cisco IOS Via tftp on RHEL
Experiences with ESXi deployments on removable media
HOWTO Install VMware Tools in Nested ESXi on ESXi
HomeLab: Cisco 3550 Switch Software Configuration Guide

 

How to Use Hpacucli in ESXi

/ Christopher Paquin / Leave a comment

Miracle_WhipWow just stumbled into this one today as I was dreading having to reboot my ESXi 4.1 boxes just to see a few new local disks.

Apparently you can install hpacucli in ESXi very easily, and whats even better is that you can install it directly on a datastore and use the install on any host that has access to that datastore. No need to reinstall on each and every host in your cluster. No need to reboot to configure your disks.

Anyway here is the link to the how to, its obviously written by a Windows Guy, but it works easy enough.

http://v-front.blogspot.com/2012/03/how-to-run-hp-online-acu-cli-for-linux.html

 

Update: Apparently HP now provides an official version of hpacucli for ESXi 5 as part of HP ESXi Utilities Offline Bundle for VMware ESXi 5.0.

Also note that I found that my HP servers with the P400 card did not detect the new logical drives, even after a rescan. Apparently a reboot is required. However my HP boxes with the P410 card did detect the new logical drives after a rescan and no reboot was required.

 

ESXi 4 Quick and Easy Find and Remove All Snapshots Via CLI

/ Christopher Paquin / 1 Comment

Cute_oh_snap_gingerbread_man_cookie_photosculpture-p1534174383042537603s98_400I needed a way to find and remove all snapshots quickly and easily from the ESXi 4 command line. Note that I am not a Windows user and would rather punch myself square in the face than use PowerShell.

So here it is… and let me warn you its really nasty

 

# for vm in `vim-cmd vmsvc/getallvms | awk '{ print $1 }' | grep -v Vmid`
> do
                                   
> vim-cmd vmsvc/snapshot.removeall $vm
> done

Note that this could actually take a really long time to run depending on the size of your snapshots.

Basically it finds the vmid of each and every vm running on the box and attempts to remove any snapshots (if they exist). Note that you will need to do this on every node in your cluster.  I plan to write a better version of this script at somepoint that will search the datastores for snapshots and the derive the vmid from that, but not today.

Configuring Remote Syslog in ESXi 4.1 via the Linux RCLI

/ Christopher Paquin / Leave a comment
Groundhog

First thing you need to know about ESXi is that it rolls its log after a reboot, meaning if your ESXi server crashes there will be no logs to review and no way of knowing what when to hell and where.

For this reason it is imperative that you setup a remote syslog server and send your logs there. Vmware support will tell you this and shame you if you have not setup remote syslogging.

Fortunately the first hit on google for “ESX syslog how to” will take you directly to the VMware KB article. You can find it here. However this page does not contain directions on how to do this via the Linux rcli, it only contains directions on how to do this via the VMA (management appliance) and from Windows PowerCLI. Really Vmware?

Follow the directions below if you run a real operating system and are not a Windows Admin.

First configure your remote ESXi host to forward syslog to your syslog server.

esxcfg-syslog –server esx04 –setserver vsyslog02 –setport 514

Then verify your settings

esxcfg-syslog –server esx04 –show

Output will appear as follows if everything worked right.

Current remote syslog server settings:
Server name : (vsyslog02)
Server port : 514

Patching ESXi 4.1 via the Linux RCLI

/ Christopher Paquin / Leave a comment
PIRATE_MASK_IMAGE_rdax_65

Great Balls of Frustration… could the documentation be anymore confusing and convoluted regarding the process of patching an ESX server via the Linux remote cli.

No, I am not running windows, and no I am not on the local ESX console, and no I am not running the Vmware Management Appliance, and most of all, no I do not want outdated instructions from 2008. I just want to download some patches to my local linux destop and patch my ESX servers. Specifically I want to install the latest and greatest Qlogic drivers to troubleshoot a SAN connectivity issue that I will probably blog about at a later date.

Anyway here is how I did what I needed to do without resorting to using a windows box.

First download the driver isos to your local Linux desktop and mount the isos up locally,

mount -o loop vmware-esx-drivers-scsi-fnic_400.1.4.0.201-1vmw.2.17.00000.491446.iso /mnt

Second locate the offline-bundle directory. I moved mine off to another directory that I created specifically for the Qlogic Driver. This way I dont have to unmount and remount the iso when i patch my other boxes.

Next put the host in maint mode.

vicfg-hostops –username root –server esx04 -o enter

Then navigate to the offline_bundle directory and run the following command, replace the bundle name that I used with the bundle name in your directory

vihostupdate –server esx04 –install –bundle 841.k1.16.2-1vmw-offline_bundle-340223.zip

Wait for the following message

Please wait patch installation is in progress …
The update completed successfully, but the system needs to be rebooted for the changes to be effective.

Then reboot

vicfg-hostops –username root –server esx04 -o reboot

Patching ESXi 4.1 to Update 1 via the VCLI in Linux

/ Christopher Paquin / Leave a comment

Brobee In early February VMware release the first update to ESXi 4.1. ESXi 4.1 Update 1 includes additonal drivers, and OS support for RHEL 6 (among others). Also there are a number of bug fixes delivered like random failures on bnx2x nic (yikes). See the entire list below.

http://www.vmware.com/support/vsphere4/doc/vsp_esxi41_u1_rel_notes.html#resolvedissues

Patching ESXi via the VCLI is pretty simple. Below are the steps that i tool to update.

  1. Download the Patch here
  2. Make sure that your host is in maintenance mode using the following command (vicfg-hostops –server esx30.atlnp1 -operation info)
  3. Install Patch (vihostupdate –server <hostname> –install –bundle update-from-esxi4.1-4.1_update01.zip)
  4. Wait a bit
  5. Reboot

You can verify that the patch installed correctly with the command below

vihostupdate –server <hostname> –query

Look for the line below…

ESXi410-Update01            2011-03-23T18:09:05 VMware ESXi 4.1 Complete Update 1 

 

Raising A Virtual Machine From the Dead, or How I Screwed Up a VM and Resurected It

/ Christopher Paquin / 2 Comments

Big-girl-zombie Something really nasty happened to me when I was working on storage vmotioning a ton of VMs onto new datastores. Basically I was not paying attention and tried to manually remove a Virtual Machine from the datastore using the datastore browser. This basically wiped out the .vmx and.vmdk files, leaving only the flat.vmdk file which could not be removed as thankfully it was in use.

Anyway once I had realized what I had done, and got my mini panic attack out of the way, I found the following kb from Vmware. Reference it here.

In order to get your VM back up and running you must create a matching .vmdk file to go with your flat.vmdk file. You do this using the command below. Note that you must know the size of your flat file in bytes.

# ls -l vmdisk0-flat.vmdk (gives you size in bytes)

Create a new virtual disk/vmdk file and a temp flat file.

# vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk

Now delete the temp flat file that you just created.

# rm temp-flat.vmdk

Rename your temp.vmdk to match the name of the flat.vmdk from your vm

mv temp.vmdk vmdisk0.vmdk

Now vi the .vmdk file and point it to the flat file at the line below. You may also need to remove the last line if you did not use thin provisioning on the original vm.

# Disk DescriptorFile
version=1
CID=fb183c20
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 8388608 VMFS "vmdisk0-flat.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "522"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.thinProvisioned = "1"

Now you can go through the process of creating a new VM via VCenter, only instead of creating a new virtual disk, you use the vmdk file that you just created. You should then be able to power on your rescued VM.

Scary!