Yellow Bricks

by Duncan Epping

esxi

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!)

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.

Adding a role to a user from the Service Console

· ·

Three weeks ago I blogged about a powershell script that can assign roles to users. This is very handy when doing scripted installs cause it seemed that it was impossible to add a role to a user from the Service Console. Today we had a discussion via email and my colleague from South Africa, Hugo, actually found out how to add a role to a certain user from the Service Console:

vmware-vim-cmd vimsvc/auth/entity_permission_add vim.Folder:ha-folder-root 'newuser' false ReadOnly true

The command used is “vmware-vim-cmd” aka “vimsh”. “vim.Folder:ha-folder-root” is on cluster level, ‘newuser’ is the username of the user you want to add the role to and the role is “ReadOnly”. False and true are values for “isgroup” and “propagate”.

Great job Hugo, and thanks for letting me know about this solution.

New version of the NetApp NFS best practices doc!

· ·

I just noticed that there’s a new version(4.3) of the NetApp on NFS best practices document online. This document has a new best practice in there that I discussed a couple of weeks ago about the “/NFS/LockDisable” and the “prefvmx.consolidateDeleteNFSLocks” settings(Page 14).

As far as I can judge at this point in time the document seems to be also following the VMware guidelines. NetApp suggests running several commands directly on the Service Console to do the desired changes. Although I do agree with their suggested changes, I don’t agree with the order of the procedure.

On page 14 in both “procedures” NetApp suggests that you enter maintenance mode before applying the changes. Which is definitely something I would also suggest. But they also suggest to exit maintenance mode right before you reboot the server. In theory this could lead to VM’s being VMotioned to the host you’re about to reboot. When this happens the VM’s will be killed without any notice, which could lead to all sorts of problems as you can imagine.

So if you’re about to make the changes NetApp suggests, please change the order and do a reboot first and exit maintenance mode when the reboot is completed.