ESX

A while back I posted about how to change the amount of RAM assigned to the COS using the SDK, however, at that time I didn’t know of a good way to do so from the command line on the box. After some digging around, testing (and consequentially breaking), I’ve discovered how to change the setting.

Turns out, someone else already knew about this (including Dominic, a.k.a vmprofessional…I swear I’ve read that kickstart file a thousand times before and never noticed the code for this)…apparently my google-fu wasn’t working for me when I was trying this before.

Remember, valid values are from 272 to 800 MB.

A few days ago I posted about setting the password complexity and other items for ESX hosts. I generally don’t use VIMA for much, as I don’t have any scripts that require periodic execution without authentication, and the logging aspect of it holds no value for me (I have a syslog server for that…). For some reason (I don’t remember why now) I was fiddling with a script on my VIMA test VM and discovered a strange error…

One thing I’ve discovered about VIMA is that when a command fails (especially the vifp commands) they give entirely useless errors back. I checked the syslog server for entries regarding the ESX host I was trying to add and discovered the following:

Read moreVIMA and ESX Password Complexity

After learning about the whole NFS fiasco I decided to create a quick bash script that would be part of my post kickstart process to apply the recommendations from NetApp as well as the fix required by VMware.

mmmmm, BASHy goodness….

Read moreBash script to apply NFS snapshot fix

Even if you use AD to authenticate your users, ESX will still check it’s local authentication mechanism for the user and their password. You can see this activity when you look in /var/log/messages after a login. For example, on my servers, when I login there are two messages…one from pam_unix saying that authentication failed and another from pam_kerberos (Active Directory) saying that authentication succeeded.

What this behaviour means is that you can have users on your ESX system that are not authenticated via Active Directory, thereby bypassing any password requirements (complexity, reuse, expiration, etc) settings you have there. Unless you adjust the default password settings in ESX, these users can have pretty much any extremely unsecure password they want, which is bad. Additionally, depending on who you work for (US Gov’t, finance, health care, etc) there may be some security compliance issues you must deal with, which usually include password requirements.

Even with Active Directory authentication, there is a local user on the ESX host for authorization. If that local user also has a local password, then the user can use either credential to login to the ESX server. Your box is only as secure as the weakest password.

Read moreESX User Authentication and Password Management

The last few posts I’ve been mentioning how much of the configuration for my ESX hosts is automated. This post I’m going to talk a little more about how that automation is done, and provide an example kickstart script. I have been holding off on this post for a while now, as I have been planning on rebuilding my PXE server, at which point I will document each step and be able to provide a much more detailed post. However, things keep getting in the way and I haven’t had time to rebuild the server yet, so this is a slightly less detailed post, but should still be enough to get you on your way 🙂 And I have no doubt that you, dear reader, are not afraid of asking questions in the comments…

This automation is currently handled (I say “currently” because I’m working to move the majority of it to a remote host and use the SDK) by kickstart when the system is loaded. Well, to be totally honest, kickstart only plays a partial role in the process…during the %post section of kickstart I copy a series of scripts from an NFS mount point into the startup process (/etc/init.d/rc3.d), which are executed at first boot and, like good one-time-only scripts, remove themselves.

This setup allows me to pxe boot a host, give it the boot command which has the host ID appended, and that’s it. I can then walk away and wait for the host to add itself to vCenter, indicating that it’s finished. Kickstart and the post install scripts then configure the hostname, ip, virtual network configuration, security policy, ntp, base user set, install any custom RPMs, etc. This makes it extremely easy for me to keep all of our hosts at the same configuration level.

In order to keep all the hosts the same I simply have to update the relevant post install script when we decide to make a global change and it will configure the host correctly the next time it is loaded/reloaded. For updating hosts that can’t be reloaded (I try to reload the hosts periodically with the newest binaries from VMware…every 4-6 months…so that the software is not a huge conglomeration of patches…I know, it’s unnecessary, but it gives me peace of mind) we use a combination of Glenn’s POSH prowess and the perl toolkit scripts I’ve created to remediate hosts en masse to our baseline configuration.

Read moreKickstart your host into configuration conformity

In order to facilitate my ability to configure all aspects of an ESX host automatically, I wanted to adjust the amount of memory that is assigned to the COS without having to use VI Client. The perl below is the result of that effort.

As always, I am not responsible for any damage caused to your infrastructure, I recommend you put your host in maintenance mode and move all VMs off of it before attempting any significant action upon it (there should be little risk involved with this script though…). The change will not take effect until you reboot the host (which can be accomplished with the hostops.pl sample script provided as a part of the Perl Toolkit).

Read moreAdjusting Console OS RAM via rCLI

I discovered that if you set the license server incorrectly, or if it can’t contact the license server, then ESX/VirtualCenter won’t let you change it. ESX seems to want to contact the old server before it will let you change to a new one.

Anyway, by modifying the /etc/vmware/license.cfg file, you can change the license server to what it should be (or just set it to an empty string and use VI Client). After modification, restart the management service: