Yellow Bricks

by Duncan Epping

vima

Update: VIMA and UPS(APC) initiated shutdown of ESXi

· ·

Joseph Holland just updated the “UPS initiated shutdown of ESXi” document I blogged about this week. This time Joseph used VIMA to get the job done. Here’s a link to the document on VI:OPS.

The procedure still requires an unsupported change on ESXi. My guess is that this will soon be fixed by using perl on VIMA. Perl enables you to use the SDK and vi-fastpass. Vi-fastpass is an authentication component which supports unattended authentication. In other words, there’s no need to store clear text passwords in script files anymore and no need to change ESXi. On twitter William Lam aka “@lamw” already hinted that he’s looking into this…

New VMware Healthcheck Script!

· ·

A couple of days ago I wrote an article about a “quick migration” script by William Lam.William seems to have some spare time on his hands or works 24 hours a day cause he just finished up a Health Check script. His script can be compared to the powershell healthcheck scripts and the Service Console script.

The script reports on the following:

  • vCenter Build/Release
  • ESX/ESXi Build/Release
  • Cluster(s) Name/Statistics (Hosts,CPU and MEM availabity, HA,DRS and DPM enabled)
  • ESX/ESXi Hardware configuration (NICs/HBAs)
  • ESX/ESXi State
  • ESX/ESXi Config (WIP)
  • ESX/ESXi Datastore summary
  • Virtual Machines summary
  • VM Storage summary
  • VM Network summary
  • VM w/Snapshots
  • VM w/RDMs
  • VM w/NPIV enabled
  • VM w/connected CD-ROMs
  • VM w/connected Floppys

For more details, please take a look at the sample report located at here. There’s an extensive VMTN blog article here which contains usage information. The requirements for this script is: vCenter 2.5, ESX(i) 3.5, VI-Perl Toolkit or VIMA.

“Quick” Migration for VM’s running on ESXi 3.5u2+

· ·

Mike D was the first one that actually wrote a powershell quick migration script that exactly does the same as Microsofts Quick Migration. (Suspend on host 1, Resume on host 2.) Yesterday William Lam emailed me about a script that he created that actually does the same as Mike D’s script. But, William’s script was specifically designed for ESXi and he used Perl to do the job. Before we get into the “is this supported with the current API/RCLI discussion“, William contacted VMware and certain procedures used will be restricted again in the next update for ESXi.

William described his script as follows:

ESXi is a formidable hypervisor solution in both licensed and free operation mode. When fully licensed in a Virtual Center cluster, ESXi’s features (VMotion, HA, DRS, VCB, etc…) are indistinguishable from ESX. One feature of importance, VMotion, is used to perform live migrations of VMs that reside on shared storage from one host to another. In free operation mode however, ESXi hosts are independent of each other, in which case, useful features like VMotion become unusable.

The motivation for this script (ghettoQuickMigrate.sh) then is to provide administrators running the free version of ESXi on several hosts with the capability to perform Hyper-V-like “quick” migrations of virtual machines residing on shared storage between the hosts. VMware’s VIMA virtual appliance was chosen as the central launch point for the quick migration process. ghettoQuickMigration.sh is executed from within VIMA and is compatible with ESXi 3.5u2+.

William wrote an extensive Communities blog post on how this script works, what the requirements are and how to set this up. Another reason for you to start using VIMA!

ESXi and warranty

· ·

I just finished my VIMA blog and 12 hours later Edward published an article on security and warranty when opening up ESXi for SSH access:

Working with VMware ESXi can be frustrating; you’re not supposed to enable the Dropbear SSH client or use its technical support mode without the assistance of a VMware support representative. System administrators, however, may be tempted to use tech support mode (or enable Dropbear) to fix problems or manage connections on the fly. Cracking this security shell, however, can void the VMware ESXi warranty and break support contracts.

Read the complete article here!

And Edward is right. The consultants and sys admins are used to SSH access to their ESX boxes and most of them opened up Dropbear SSH on their ESXi box as soon as they heard it was possible. That’s why I think everyone should start investigating VIMA. When I got some more time on my hands I will try to post more on VIMA.

VMotioning your Service Console?!

· ·

Some of you might have looked into VIMA already. Those of you that didn’t please check it out because I expect this to be the way that VMware is heading. Note, I don’t know if it really is the way VMware is heading, but a Service Console with VMotion capabilities sounds like a winner to me. A little birdie also just told me that APC, the UPS Company, is finishing their VIMA Compatible UPS software agent!

The cool thing about VIMA is that it includes the RCLI commands, the Perl toolkit and a logger daemon named vilogd. The last one will be the topic for this blog. So what does this logger daemon include?
The vilogd daemon collects all the logs that are available through the DiagnosticManager VI API:

  • ESX/ESXi3.x service log
  • VI Client Agent log
  • Virtual Machine kernel core file
  • System log

First add servers to the VIMA appliance:

sudo vifp addserver esx01.localdomain
sudo vifp addserver esx02.localdomain

Now you will need to enable the vilogd for the servers you added:

vilogger enable

So when you’ve enabled it you could also set the max log size(default 5MB) or for instance the amount of log rotations(default 5 rotations). So the way you do this is as follows:

vilogger updatepolicy --maxfilesize 10 --collectionperiod 5 --numrotation 10

So the maximum filesize of a log will be 10MB. When the 10MB has been reached it will rotate the log files, their will be 10 log files kept by setting “numrotation”. The log files will be collected every 5 seconds.

As you can see, it’s kinda like a syslog daemon but in my opinion a bit easier to setup. I would love to see a web interface of some sort that immediately points you out to possible problems, and with a bit of work it should also be possible to direct people to kb articles on these problems. But we will just have to wait and see what will be coming up. I honostly don’t know.