Yellow Bricks

by Duncan Epping

ESX

VMware CPU Host Info

· ·

Richard Garsthagen managed to find some spare time and update his ESX Host CPU info tool:

Interested in knowing if all your physical ESX servers are the same? VMware CPU Host Info will help you find out. The application gathers the important system information from your hosts and puts this in one single overview.

The program will tell you if your servers are VT capable and more important if this feature is turned on. I have found that on most my servers, this feature is disabled in the BIOS.

At some point in time VMware will provide a new cool feature called FT, this ‘Fault Tolerant’ feature will only work with the latest processors. This program will also let you know if your processors are new enough 🙂 (you have to have harpertown or above).

At the Login screen just provide your username, password and the IP/DNS of your Virtual Center. After the login, the program will collect from all hosts the Vendor, Model, CPU Types and the CPU feature bits.

You can connect the tool to multiple VC’s at the same time and it will report useful info like CPU Type and Features which might be handy if you’ve got a dozen of hosts and you want to create clusters based on VMotion compatibility. And as you can see in the screenshot below it also detects if you’re hosts are Fault Tolerance compatible. Visit his blog and pick it up.

Let’s hope Richard can keep finding time to do cool stuff like this or to blog on a more regular base again!

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.

NetApp storage best practices revised!

· ·

About a week ago I wrote about the new version of the NetApp best practices pdf TR-3428. I emailed with Vaughn about the fact that leaving maintenance mode before the reboot might not be the smartest thing to do. Vaughn aggreed and replied that the document would be revised soon.

This would need to go through the normal process which could take weeks. Somehow Vaughn managed to speed things up and just published the new version, 4.4, of TR-3428.

Read the document, even if you don’t own a NetApp there’s still useful info in there! In my opinion it’s one of the best VMware documents I’ve seen so far from a vendor. (Although the Cisco pdf is also a great read!)

Hyper-V vs ESX performance

· ·

There has been a lot of talk on Hyper-V vs ESX performance. I can imagine that no one believes performance statements coming from either VMware or Microsoft. Kenon Owens from VMware posted a blog article on this topic. Yes Kenon is from VMware but the performance tests has been done by an independent company.

The complete performance test has been captured in one graph:

Read Kenon’s blog for more info. Great article,

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.