FatMin

How to Use Hpacucli in ESXi

Wow 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

I 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

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.atlis1)
Server port : 514

 

Patching ESXi 4.1 via the Linux RCLI

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

Latest Vmware Tools Download

I would actually be suprised that I was not aware of this site previously, if I had not ever been to vmware.com and attempted to find a specific software in the past. Needless to say, its rather dificult to find exactly what you are looking for there.

So... apparently vmware calls the latest vmware tools, OSPs, or "Operating System Specific Packages"

The site is below... Navigate to the OS specific to your needs and go to town.

http://packages.vmware.com/tools

 

 

 

 

Considering Alternatives to VMware

Interested in doing some serious virtualization on Cisco's new UCS C-Series line of servers? Seriously, why would'nt you be.  Cisco's UCS C460 M2 server supports up to 4 intel E7-4800 processors -- these are 10 core procs people -- and up to 1tb of memory. Thats 40 cores in 4 RU!

I am eager to get one of these servers, or even one or the two proc models into our lab and test them out. I have been hearing great things about them and think they would be perfect virtualization servers for our non-production infrastructure where we seem to have at least 6 or 7 different QA environments. Plus Vmware and Cicso partnered together on these things.

But slow your roll cowboy, with Vmware's recent licensing announcement regarding Vsphere 5 and vRam limitations, it would take 11 Enterprise plus licenses to utilize 1tb of memory. At 3 to 4k per license you are talking about 40k in licensing for one server. Nasty!

Enter the alternatives in the virtualization world. Citrix ZenServer and Redhat (RHEV-M). Hell I'll even mention Microsoft's Hyper-V.  However, to move to a different technology you need to be able to get your Vmware vms off of ESX and onto your new virtualization flavor of choice.

Here is how to do it in XenServer. Note that I have not tried this in the lab yet, but trust me i will. I will also do the same with RHEV-M, its its only $750 per socket per year.

http://support.citrix.com/article/CTX116603

Sure the alertnatives are not as advanced as Vmware ESX right now, but they making improvements slowly but surely, and I am sure that the recent Vmware licensing announcements are only going to bring more potential customers to other virtualization vendors which will only help to further mature their products.

Find out more about the Cicso USC C-Series via the link below

http://www.cisco.com/en/US/prod/ps10265/ps10493/c_series_comparison.html

 

 

Removing a Virtual Disk from CentOS/RHEL via vSphere Client

When you right click on a VM via the vSphere client and click edit setting you will see your hard disk enumerated as follows:

^{Hard disk 1 - Virtual Disk}

^{Hard disk 2 - Virtual Disk}

However CentOS/RHEL enumerates your disks using a different nomenclature. See below:

<sup>Disk /dev/sda: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1044     8385898+  83  Linux
/dev/sda2            1045        2349    10482412+  83  Linux
/dev/sda3            2350        2610     2096482+  82  Linux swap

Disk /dev/sdb: 268.4 GB, 268435456000 bytes
255 heads, 63 sectors/track, 32635 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       32635   262140606   83  Linux</sup>

^{[[truncated]]}

While you can assume that the your first disk listed in ESX is your first disk listed via the OS, this is not always the case. You can attempt to compare disk sizes to further determine which disk is which, however the sizes do not always match up.

The best way to identify disks is via the Virtual Device Node, which is visable via the virtual disk properties in ESX and via the command lsscsi in Centos/OS.

More than likely lsscsi is not installed via default so you are going to either need to install via yum, or download a rpm and install. Once installed run as seen below

^{>lsscsi
[0:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
[0:0:1:0]    disk    VMware   Virtual disk     1.0   /dev/sdb
[0:0:2:0]    disk    VMware   Virtual disk     1.0   /dev/sdc
[0:0:3:0]    disk    VMware   Virtual disk     1.0   /dev/sdd}

The first two numbers are unique to the scis contoller and the second two numbers indicate the disk number which can be seen in the disk properties in the vsphere client properties.

For example in vmware Hard disk 4 has a virtual device id of "SCSI (0:3) Hard Disk 4, and by running lsscsi I know for sure that this disk is /dev/sdd. Now I can remove the disk with confidence from esx and have to worry that I removed the wrong disk.

Patching ESXi 4.1 to Update 1 via the VCLI in Linux

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

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!

 

ESXi 4.1 - Three Ways to Kill a Virtual Machine from the Command Line.

You can log into an esxi 4.1 host and issue the following command to get a list of all running and registered VMs.

# vm-support -x

The vm-support command above will give you the World ID of the VM that you are looking to kill.

# vm-support -X <World_ID> –w <dir>

Another way to kill or shutdown a VM is with the vim-cmd command. Use the command below to find your vmid

vim-cmd vmsvc/getallvms\

Then kill it with...

vim-cmd vmsvc/power.off <vmid>

The nastiest and uncleanest method is to actually kill the unix PPID (parent process id) of the VM. Take a look at the command below and subsitute your VM's name. The PPID is in bold.

# ps | grep  <my_vm_name>
10071899      vmm0:<my_vm_name>
10051474 10071896 mks:<my_vm_name>   /bin/vmx
10084243 10071896 vcpu-0:<my_vm_name> /bin/vmx

Reference here