Virtualization and Security

Security is huge when it comes to virtualization. The extra moving parts require a special care and feeding.  The Defense Information Services Agency is basically the IT department for the US Defence Department. They have an arm, called the Information Assurance Support Environment. The IASE is a has some serious information about securing any system. They post Security Technical Implementation Guides (STIGS) and Security Checklists that are very comprehensive. They even have STIGs and Checklists for all the different versions of winders. Some of the information is specific to the DoD, but those things, like certificates, etc. still have a place in any IT shop. I subscribe to their newsletter, so they just came to mind again because they posted a Draft XenApp STIG. I glanced at the docs, but they look pretty deep and I have reading narcolepsy…

So, why do I bring this up? They also posted a STIG for ESX Server a while ago and recently posted an updated Security Checklist for ESX. I know that Sid used these as a guide for his kickstart / post installation script. When coupled with the Unix STIG and Checklist, you will get a very secure system. So go check them out. They a free and that is my favorite price. So go get some.

:o)

ESX Datastore sizing and allocation

I have been seeing a lot of activity in the VMTN forums regarding datastore sizing and free space.  That said I decided to write a post about this topic.  There are endless possibilities when it comes to datastore sizing and configurations but I’m going to focus on a few keep points that should be considered when structuring your ESX datastores.

All VM files kept together

In this configuration all VM files are kept together on one datastore.  This includes the vmdk file for each drive allocated to the VM, the vmx file, log files, the nvram file, and the vswap file.  When storing virtual machines this way there are some key considerations that need to be taken into account.  You should always allow for 20% overhead on your datastores to allow enough space for snapshots and vmdk growth if necessary.   When allocating for this overhead you have to realize that when a VM is powered on a vswap file is created for the virtual machine equal in size to the VM’s memory.  This has to be accounted for when allocating your 20% overhead.

For Fiber Channel and iSCSI SAN’s you should also limit the number of VM’s per datastore to no more than 16.  WIth these types of datastores file locking and scsi reservations create extra overhead.  Limiting the number of VM’s to 16 or less reduces the risk of contention on the datastore.  So how big should you make your datastores?  That’s a good question and it will vary from environment to environment.  I always recommend 500GB as a good starting point.  This is not a number that works for everyone but I use it because it helps limit the number of vm’s per datastore.

Consider the following your standard VM template consist of two drives an OS drive and a Data drive.  Your OS drive is standardized at 25Gb and your Data drives default starts at 20Gb with larger drives when needed.  Your standard template also allocated 2Gb of memory to your VM.  Anticipating a max of 16 VM’s per datastore I would allocate as follows:

((osdrive + datadrive) * 16) = total vm disk space + (memory * 16) =vm disk & vswap + (16 * 100Mb(log files) = total VM space needed * 20% overhead

(25 + 20) * 16 = 720Gb + ((2Gb * 16)=32) = 752Gb + ((16 * 100mb) = 1.6Gb) = 753.6Gb * 20% = 904.32Gb Round up to 910Gb needed

Depending on how you carve up your storage you may want to bump this to 960Gb or 1024Gb so as you can see the 500Gb rule was proven wrong for this scenario.  The point is you should have a standardized OS and data partition to properly estimate and determine a standardized datastore size.  This will never be perfect as there will always be VM’s that are anomalies.

Keep in mind if you fill your datastore and don’t leave room for the vswp file that is created when a VM powers on you will not be able to power on the VM.  Also if you have a snapshot that grows to fill a datastore the VM will crash and your only option to commit the snapshot will be to add an extent to the datastore because you will need space to commit the changes.  Extents are not recommended should be avoided as much as possible.

Separate VM vswap files

There are a number of options available in Virtual Infrastructure on how to handle the VM’s vswap file.  You can set the location of this file at the vm, the ESX Server, or the cluster.  You can choose to locate it on a local datastore or one or more shared datastores. Below are some examples:

Assign a local datastore per ESX server for all VM’s running on that server.

This option allows you to utilize a local vmfs datastore to store the VM’s vswap saving valuable disk space.  When using a local datastore I recommend allocating enough storage for all the available memory in the host + 25% for memory over subscription.

Create one shared datastore per ESX cluster.

In this option you can set one datastore at the cluster level for all vswap files.  This allows you to create one large datastore and set the configuration option once and never worry about it again.  Again I would allocate enough space for the total amount of memory for the whole cluster +25% for over subscription.

Multiple shared datastores in a cluster.

In this option you have different scenarios.  You can have one shared datastore per esx hosts in the cluster or one datastore for every two servers in the cluster, etc..  You would need to assign the vswap datastore at the esx host level for this configuration.

Note: When moving the vswap to a separate location it can impact the performance of vmotion.  It could extend the amount of time it takes for the vm to fully migrate from one host to another.

Hybrid Configuration.

Just as it’s possible to locate the vswap on another datastore it is also possible to split the vmdk disks on to separate datastores.  For instance you could have datastores for:

OS Drives
Data Drives
Page Files
vSwap files

To achieve this you would tell the vm where to create the drive and have different datastores allocated for these different purposes.  This is especially handy when planning to implement DR.  This allows you to only replicate the data you want and skip the stuff you don’t like the vswap and page files.  With this configuration you can also have different replication strategies for the data drives an OS drives.

Hope you found this post useful.

Script to Restart VMware Tools Remotely

I was “forced” to learn how Powershell and the VI Toolkit works for an engagement a few months ago. Once you learn how powershell works and how the VI Toolkit integrates with Powershell, you will love it. This is coming from a linux guy who sees some of the VBScript stuff and just goes “HUH?!?” If you like VB SCripts, check out this post on Jase’s Place. Back in the day, I knew DOS scripting pretty well and I have learned rudimentary bash and perl scripting. To be frank, Powershell was easy for a knucklehead like me to pick up. I use it frequently to automate tasks in VI3 and the winders VMs it manages.

In my last post, I mentioned that VCB snapshots will cause VMware Tools to appear to go off line, even though they are still running. The fixes were to restart the management services on the host or login/logout of the guest. Restarting the management services on the host could cause issues if someone set up to automatically start VMs on boot. Logging in to the VMs is fine unless you have hundreds of VMs.

A third option is to restart the VMware Tools service. This is something that can easily be scripted as long as you have admin access to the guest via RPC services. There are a few methods to script the restart of services on a server remotely. The first is using the sc.exe utility. The syntax of the script looks like this:

sc.exe \guestname stop VMTools
sc.exe \guestname start VMTools

This can be easily scripted using the good-old DOS for command. Create a text file (C:scriptsserverlist.txt) with all of the servers that need to have the VMware Tools service restarted, one guest per line in the file so it looks like this:

guest1
guest2
guest3
guest4

Then run a command that looks like this:

For /F %%SERVER in C:scriptsserverlist.txt do
sc.exe \%SERVER stop VMTools
sleep 10
For /F %%SERVER in C:scriptsserverlist.txt do
sc.exe \%SERVER start VMTools

You can get the sleep utility in the Resource Kit Tools for Windows 2003. A 10 second pause seems to work pretty well to make sure the service actually stops.

Since I lost all of my DOS scripting chops, I only know how to automate this fully using the VI Toolkit and Powershell. The script below will use the VI Toolkit to automatically create a list of guests that report as not having VMware Tools running and pass that information to standard powershell commands to stop and start the services:

#Connect to the vCenter Server
Connect-ViServer <vCenter.FQDN>

#Get a list of guests where VMware Tools are not running
$servers = get-vm | where { $_.PowerState -eq “PoweredOn” } | Get-VMGuest | where { $_.State -ne “Running” } | select vmName, State

# Stop VMTools Service
foreach ($srv in $servers)
{

Write-Host “Stopping services on $srv”
# Get the VMTools Service
$Service = get-wmiobject -ComputerName $srv -query “select * from win32_service where name=’VMTools'”
if ($Service -ne $null)

#Stop the VMTools Service
{$Service.StopService()}

Sleep 10
Write-Host “Starting services on $srv”

#Start the VMTools Service
$Service.StartService()
}

Another thing I recently needed was a quick way to list the guests with snapshots as a quick method to make sure VCB exited properly. You can use this:

Get-VM | Get-Snapshot | Select VM, Name, Created, Description

Well, there you have it. Script your VMware Tools restart…
:o)

Automated Deployment of ESX Hosts Part III

This is Part III of a multi-part blog. If you haven’t read Part I or II I recommend that you do before continuing.

In Part II we developed a standard build for our hosts that we are going to use to build our automated build script.  Keep in mind the information I provided in my standard build is not all inclusive and is limited for the demostration of building the script.

First we will start with the kickstart portion of the script.  The kickstart is what configures the basic part of the installation that you would normally do manually from the CD.  The ESX 3.5 kickstart is a modified version of anaconda.

In the begining of our script we have the Regional Settings that we need to set. Below are the regional settings for my installation.

# Regional Settings
keyboard us
lang en_US
langsupport --default en_US
timezone --utc America/New_York

Next we have some important installation settings. Part of the installtion section is the location of our ESX installations. In my script I have included some samples. cdrom, ftp, & http. I have chosen http for my installation so I did not comment http out. I personally prefer http because it can be much less problematic than ftp or nfs.


# Installatition settings
skipx
mouse none
firewall --disabled

# Authentication
auth –enableshadow –enablemd5

# Unencrypted root password: password
rootpw –iscrypted $1$5a17$In5zYe6YsCty76AycpGaf/

#Reboot Server after finished
reboot

#install ESX3.5U3 do not perform upgrade
install

#Location of installation medium
#cdrom
#url –url ftp://192.168.12.200/esx/esx353/
url –url http://192.168.12.200/esx/esx353/

In this next secition we are going to be configuring out hard disk drive partitions and boot loader options. You’ll notice that my disk drive is cciss/c0d0. This is because I will be installing on HP hardware with HP SCSI controllers. If I were to script this for IBM, DELL, or other servers I would typically utilize sda for my drive.


# Bootloader options
bootloader --driveorder=cciss/c0d0 --location=mbr

# Partitioning – This area is where you define your partitioning scheme
clearpart –all –initlabel –drives=cciss/c0d0
part /boot –fstype ext3 –size 100 –ondisk=cciss/c0d0 –asprimary
part swap –size 1600 –ondisk=cciss/c0d0 –asprimary
part / –fstype ext3 –size 10240 –ondisk=cciss/c0d0 –asprimary
part /var –fstype ext3 –size 8192 –ondisk=cciss/c0d0
part /tmp –fstype ext3 –size 4096 –ondisk=cciss/c0d0
part /opt –fstype ext3 –size 5120 –ondisk=cciss/c0d0
part /home –fstype ext3 –size 5120 –ondisk=cciss/c0d0
part None –fstype vmkcore –size 100 –ondisk=cciss/c0d0
part None –fstype vmfs3 –size 1 –grow –ondisk=cciss/c0d0

In this next secition we are configuring the networking settings for our Service Console. I recommend always using nic0(eth0) (vmnic0) for the Service Console and always perform your automated installation over this network interface. It is possible to do an automated installation over a different network interface but requires additional scritping to properly allcoate the interfaces.


# Network Configurations for service console. This will be applied to the Network interface that the kickstart is performed on. We are also choosing to not create a default portgroup.
network --device eth0 --bootproto static --ip 192.168.10.100 --netmask 255.255.255.0 --gateway 192.168.10.1 --nameserver 192.168.5.30 --hostname vmware1.sidtest.local --addvmportgroup=0

# VMWare License options
#Accept VMware License Agreement
vmaccepteula
#Configure host to talkt o license server
vmlicense –mode=server –server=27000@vcenter.sidtest.local –edition=esxFull –features=backup,vsmp

%vmlicense_text

%packages
@base

%post

That completes the kickstart portion of our script.

Everything beyong the %post portion of the kickstart is our post installation script.  The post installtion script is run on the first boot of the server.  A post installation script can contain bash, perl and other scripting but for simplicity I will be using bash scripts executing ESX and some other commands for my post installation part of the script.

I will start my Post Installation script off with the netowork configuration for the host.

#!/bin/sh
###### Configure Networking##########
###Setup vSwitch0######
echo Adding vmnic2 to vSwitch0 >> /var/log/post_install.log
esxcfg-vswitch -L vmnic2 vSwitch0

######### Add PortGroup for VMotion vmkernel adapter #########
echo Creating VMotion Portgroup
esxcfg-vswitch -A “VMotion” vSwitch0

## Tag VLAN to VMkernel ##
esxcfg-vswitch -p VMotion -v 301 vSwitch1

## Creating VMKnic and Assigning VMkernel IP and Gateway ##
echo Assigning VMKernel IP and Gateway – Please Wait
echo Assigning VMKernel IP and Gateway – Please Wait >> /var/log/post_install.log
esxcfg-vmknic -a -i 192.168.12.100 -n 255.255.250.0 “VMotion”
esxcfg-route 192.168.12.1

## Restart the Managment service so vimsh will notice changes to vSwitch0 ##
service network restart
sleep 300
service mgmt-vmware restart

## Enable vmkernel on vmk0 for vmotion ##
echo Enabling vMotion on VMkernel interface – Please Wait
echo Enabling vMotion on VMkernel interface >> /var/log/post_install.log
vmware-vim-cmd hostsvc/vmotion/vnic_set vmk0 >> /var/log/post_install.log

## Set both vmnic0 and vmnic2 to active for vSwitch0 ##
echo Confgiuring both vmnic0 and vmnic2 to be active for vSwitch0
echo Confgiuring both vmnic0 and vmnic2 to be active for vSwitch0 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –nicorderpolicy-active=vmnic0,vmnic2 vSwitch0 >> /var/log/post_install.log

## Configure NIC Priority Order for VMkernel and Service Console ##
echo Configuring NIC Priority for SC and VMkernel – Please Wait
echo Configuring NIC Priority for SC and VMkernel >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/portgroup_set –nicorderpolicy-active=vmnic0 –nicorderpolicy-standby=vmnic2 vSwitch0 “Service Console” >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/portgroup_set –nicorderpolicy-active=vmnic2 –nicorderpolicy-standby=vmnic0 vSwitch0 “VMotion” >> /var/log/post_install.log

## Reject Forged Transmits and Mac Address Changes for vSwitch0 ##
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch0
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch0 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –securepolicy-forgedxmit=false vSwitch0 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –securepolicy-macchange=false vSwitch0 >> /var/log/post_install.log

## Reject Forged Transmits and Mac Address Changes for Service Console PortGroup ##
echo Rejecting Forged Transmits and MAC Address CHanges for Service Console PortGroup
echo Rejecting Forged Transmits and MAC Address CHanges for Service Console PortGroup >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/portgroup_set –securepolicy-forgedxmit=flase vSwitch0 “Service Console” >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/portgroup_set –securepolicy-macchange=false vSwitch0 “Service Console” >> /var/log/post_install.log

## Reject Forged Transmits and Mac Address Changes for VMotion Portgroup ##
echo Rejecting Forged Transmits and MAC Address CHanges for VMotion PortGroup
echo Rejecting Forged Transmits and MAC Address CHanges for VMotion PortGroup >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/portgroup_set –securepolicy-forgedxmit=flase vSwitch0 “VMotion” >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/portgroup_set –securepolicy-macchange=false vSwitch0 “VMotion” >> /var/log/post_install.log

echo Settings for vSwitch0 complete
echo Settings for vSwitch0 complete >> /var/log/post_install.log

####### Setup vSwitch1 #######
echo Configuring settings for vSwitch1 - Please Wait
echo Configuring settings for vSwitch1 - Please Wait >> /var/log/post_install.log
## Creating vSwitch1, assigning vmnics, creating portgroups and assigning vlans ##
echo Creating vSwitch1
echo Creating vSwitch1 >> /var/log/post_install.log
esxcfg-vswitch -a vSwitch1
echo Adding vmnic5, and vmnic7 to vSwitch1
echo Adding vmnic5, and vmnic7 to vSwitch1 >> /var/log/post_install.log
esxcfg-vswitch -L vmnic5 vSwitch1
esxcfg-vswitch -L vmnic7 vSwitch1

 

echo Creating PortGroups on vSwitch1
echo Creating PortGroups on vSwitch1 >> /var/log/post_install.log
esxcfg-vswitch -A "VLAN2" vSwitch1
esxcfg-vswitch -A "VLAN15" vSwitch1
esxcfg-vswitch -A "VLAN150" vSwitch1
esxcfg-vswitch -A "VLAN151" vSwitch1
esxcfg-vswitch -A "VLAN152" vSwitch1

 

echo Adding vlan assignments to PortGroups on vSwitch1
echo Adding vlan assignments to PortGroups on vSwitch1 >> /var/log/post_install.log
esxcfg-vswitch -p VLAN2 -v 2 vSwitch1
esxcfg-vswitch -p VLAN15 -v 15 vSwitch1
esxcfg-vswitch -p VLAN150 -v 150 vSwitch1
esxcfg-vswitch -p VLAN151 -v 151 vSwitch1
esxcfg-vswitch -p VLAN152 -v 152 vSwitch1

 

## Restart the Managment service so vimsh will notice changes to vSwitch1
service mgmt-vmware restart
## Wait 4 minutes for the hostd-vmdb service to fully start running it can take awhile for it to fully load and vimsh to work ##
echo Sleeping for 4 minutes - Please Wait
sleep 240
## Setting all vmnics to active for vSwitch1 ##
echo Confgiuring all vmnics to be active for vSwitch1
echo Confgiuring all vmnics be active for vSwitch1 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy --nicorderpolicy-active=vmnic5,vmnic7 vSwitch1 >> /var/log/post_install.log
## Reject Forged Transmits and Mac Address Changes for vSwitch1 ##
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch1
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch1 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy --securepolicy-forgedxmit=false vSwitch1 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy --securepolicy-macchange=false vSwitch1 >> /var/log/post_install.log
echo Settings for vSwitch1 complete
echo Settings for vSwitch1 complete >> /var/log/post_install.log
 echo Configuring settings for vSwitch2 - Please Wait
echo Configuring settings for vSwitch2 - Please Wait >> /var/log/post_install.log

## Creating vSwitch2, assigning vmnics, creating portgroups and assigning vlans ##
echo Creating vSwitch2
echo Creating vSwitch2 >> /var/log/post_install.log
esxcfg-vswitch -a vSwitch2

echo Adding vmnic4, vmnic6 to vSwitch2
echo Adding vmnic4, vmnic6 to vSwitch2 >> /var/log/post_install.log
esxcfg-vswitch -L vmnic6 vSwitch2
esxcfg-vswitch -L vmnic4 vSwitch2

echo Creating PortGroups on vSwitch2
echo Creating PortGroups on vSwitch2 >> /var/log/post_install.log
esxcfg-vswitch -A “VLAN200” vSwitch2
esxcfg-vswitch -A “VLAN201” vSwitch2
esxcfg-vswitch -A “VLAN203” vSwitch2

echo Adding vlan assignments to PortGroups on vSwitch2
echo Adding vlan assignments to PortGroups on vSwitch2 >> /var/log/post_install.log
esxcfg-vswitch -p VLAN200 -v 200 vSwitch2
esxcfg-vswitch -p VLAN201 -v 201 vSwitch2
esxcfg-vswitch -p VLAN203 -v 203 vSwitch2

## Restart the Managment service so vimsh will notice changes to vSwitch2 ##
service mgmt-vmware restart

## Wait 4 minutes for the hostd-vmdb service to fully start running it can take awhile for it to fully load and vimsh to work ##
echo Sleeping for 4 minutes – Please Wait
sleep 240

## Setting all vmnics to active for vSwitch2 ##
echo Confgiuring all vmnics to be active for vSwitch2
echo Confgiuring all vmnics be active for vSwitch2 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –nicorderpolicy-active=vmnic4,vmnic6 vSwitch2 >> /var/log/post_install.log

## Reject Forged Transmits and Mac Address Changes for vSwitch2 ##
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch2
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch2 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –securepolicy-forgedxmit=false vSwitch2 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –securepolicy-macchange=false vSwitch2 >> /var/log/post_install.log

echo Settings for vSwitch2 complete
echo Settings for vSwitch2 complete >> /var/log/post_install.log

echo Configuring settings for vSwitch3 – Please Wait
echo Configuring settings for vSwitch3 – Please Wait >> /var/log/post_install.log

## Creating vSwitch3, assigning vmnics, creating portgroups and assigning vlans ##
echo Creating vSwitch3
echo Creating vSwitch3 >> /var/log/post_install.log
esxcfg-vswitch -a vSwitch3

echo Adding vmnic1 and vmnic3 to vSwitch3
echo Adding vmnic10and vmnic3 to vSwitch3 >> /var/log/post_install.log
esxcfg-vswitch -L vmnic1 vSwitch3
esxcfg-vswitch -L vmnic3 vSwitch3

echo Creating PortGroups on vSwitch3
echo Creating PortGroups on vSwitch3 >> /var/log/post_install.log
esxcfg-vswitch -A “VLAN400” vSwitch3
esxcfg-vswitch -A “VLAN401” vSwitch3

echo Adding vlan assignments to PortGroups on vSwitch3
echo Adding vlan assignments to PortGroups on vSwitch3 >> /var/log/post_install.log
esxcfg-vswitch -p VLAN400 -v 400 vSwitch3
esxcfg-vswitch -p VLAN401 -v 401 vSwitch3

## Restart the Managment service so vimsh will notice changes to vSwitch3 ##
service mgmt-vmware restart

## Wait 4 minutes for the hostd-vmdb service to fully start running it can take awhile for it to fully load and vimsh to work ##
echo Sleeping for 4 minutes – Please Wait
sleep 240

## Setting all vmnics to active for vSwitch3 ##
echo Confgiuring all vmnics to be active for vSwitch3
echo Confgiuring all vmnics be active for vSwitch3 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –nicorderpolicy-active=vmnic1,vmnic3 vSwitch3 >> /var/log/post_install.log

## Reject Forged Transmits and Mac Address Changes for vSwitch3 ##
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch3
echo Rejecting Forged Transmits and MAC Address CHanges for vSwitch3 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –securepolicy-forgedxmit=false vSwitch3 >> /var/log/post_install.log
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –securepolicy-macchange=false vSwitch3 >> /var/log/post_install.log

echo Settings for vSwitch3 complete
echo Settings for vSwitch3 complete >> /var/log/post_install.log 

Next I will configure the firewall rules to allow all the services I need to communicate in/out of the ESX host.

echo Configuring Firewall Rules - Please Wait
echo Configuring Firewall Rules >> /var/log/post_install.log

esxcfg-firewall -o 2381,tcp,in,hpim
esxcfg-firewall -o 2381,tcp,out,hpim
esxcfg-firewall -o 88,tcp,out,KerberosClient
esxcfg-firewall -o 6389,tcp,in,Naviagent
esxcfg-firewall -o 88,udp,out,
esxcfg-firewall -o 464,tcp,out,KerberosPasswordChange
esxcfg-firewall -e smbClient
esxcfg-firewall -e sshClient
esxcfg-firewall -e ntpClient
esxcfg-firewall -e CIMHttpServer
esxcfg-firewall -e snmpd
echo Configuring Firewall rules complete
echo Configuring Firewall rules complete >> /var/log/post_install.log

Here we are going to configure our DNS Servers 

echo Configuring DNS Servers - Please Wait
echo Configuring DNS Servers >> /var/log/post_install.log
echo Making backup of /etc/resolv.conf
echo Making backup of /etc/resolv.conf >> /var/log/post_install.log
cp /etc/resolv.conf /etc/resolv.conf.bak
echo nameserver 192.168.5.20 > /etc/resolv.conf
echo nameserver 192.168.5.21 >> /etc/resolv.conf

echo DNS Server configuration complete
echo DNS Server configuration complete >> /var/log/post_install.log

Now we will configure our NTP Settings.

echo configuring NTP Settings - Please Wait
echo configuring NTP Settings >> /var/log/post_install.log
echo Making backup of /etc/ntp.conf
echo Making backup of /etc/ntp.conf >> /var/log/post_install.log
cp /etc/ntp.conf /etc/ntp.conf.bak
echo restrict default kod nomodify notrap noquery nopeer > /etc/ntp.conf
echo restrict 127.0.0.1 >> /etc/ntp.conf
echo server 192.168.5.30 >> /etc/ntp.conf
echo server 192.168.5.31 >> /etc/ntp.conf
echo server 192.168.5.32 >> /etc/ntp.conf
echo driftfile /var/lib/ntp/drift >> /etc/ntp.conf
echo broadcastdelay 0.008 >> /etc/ntp.conf
echo Making backup of /etc/ntp/step-tickers
echo Making backup of /etc/ntp/step-tickers >> /var/log/post_install.log
cp /etc/ntp/step-tickers /etc/ntp/step-tickers.bak
echo server 192.168.5.30 > /etc/ntp/step-tickers
echo server 192.168.5.31 > /etc/ntp/step-tickers
echo server 192.168.5.32 > /etc/ntp/step-tickers
chkconfig --level 345 ntpd on
hwclock --systohc
service ntpd start >> /var/log/post_install.log
echo NTP settings complete
echo NTP settings complete >> /var/log/post_install.log
echo Restarting VMware Management Service
echo Restarting VMware Management Service >> /var/log/post_install.log
echo Sleeping for 4 minutes - Please Wait
service mgmt-vmware restart >> /var/log/post_install.log
sleep 240
echo VMware management Service restarted
echo VMware management Service restarted >> /var/log/post_install.log

Now I will set the service consoel memory to 800Mb

echo Setting Service Console Memory to 800Mb
echo Setting Service Console Memory to 800Mb >> /var/log/post_install.log

sed -i 's/memSize = "272"/memSize = "800"/g' /etc/vmware/esx.conf
esxcfg-boot -g
esxcfg-boot -b
echo Service Console Memory assigned to 800Mb complete
echo Service Console Memory assigned to 800Mb complete >> /var/log/post_install.log

Now we will configure AD integration for service console logins

echo Configuring PAM AD Integration
echo Configuring PAM AD Integration >> /var/log/post_install.log
esxcfg-auth --enablead --addomain=hq.nt.newyorklife.com --addc=hq.nt.newyorklife.com >> /var/log/post_install.log
echo Backing up /etc/krb5.conf
echo Backing up /etc/krb5.conf >> /var/log/post_install.log
cp /etc/krb5.conf /etc/krb5.conf.bak
echo Creating /etc/krb5.conf
echo [domain_realm] > /etc/krb5.conf
echo sidtest.local = sidtest.local >> /etc/krb5.conf
echo .sidtest.local = sidtest.local >> /etc/krb5.conf
echo [libdefaults] >> /etc/krb5.conf
echo default_realm = sidtest.local >> /etc/krb5.conf
echo [realms] >> /etc/krb5.conf
echo sidtest.local = { >> /etc/krb5.conf
echo admin_server = sidtest.local:464 >> /etc/krb5.conf
echo default_domain = sidtest.local >> /etc/krb5.conf
echo kdc = dc1.sidtest.local:88 >> /etc/krb5.conf
echo kdc = dc2.sidtest.local:88 >> /etc/krb5.conf
echo } >> /etc/krb5.conf
echo Finished Configuring PAM AD Integration
echo Finished Configuring PAM AD Integration >> /var/log/post_install.log
echo Adding authorized Active Directory users - Please Wait
echo Adding authorized Active Directory users >> /var/log/post_install.log
useradd -m ssmith -g wheel -G adm
useradd -m jbower -g wheel -G adm
useradd -m cobrian -g wheel -G adm
useradd -m talmeda -g wheel -G adm
useradd -m t01bo3L -g wheel -G adm
useradd -m t44bblk -g wheel -G adm
echo Autorized Active Directory Users added
echo Autorized Active Directory Users added >> /var/log/post_install.log

 

Now we will prevent root login from the physical console

 

echo Preventing root form loggin on to console
echo Preventing root form loggin on to console >> /var/log/post_install.log
echo Backing up /etc/securetty
echo Backing up /etc/securetty >> /var/log/post_install.log
mv /etc/securetty /etc/securetty.bak
touch /etc/securetty
echo Preventing root form loggin on to console complete
echo Preventing root form loggin on to console complete >> /var/log/post_install.log

Here we will set our local password policy for all local accounts

echo Setting local password policy
echo Setting local password policy >> /var/log/post_install.log
echo Setting maximum number of days to keep a password
esxcfg-auth --passmaxdays=90
echo Setitng password minimum days between changes
esxcfg-auth --passmindays=1
echo Setting Password warning time befor change required
esxcfg-auth --passwarnage=14
echo Setting local password policy complete
echo Setting local password policy complete>> /var/log/post_install.log

Now let’s set the Message of Day and Welcome.js message

echo COnfiguring MOTD login banner – Please Wait
echo COnfiguring MOTD login banner >> /var/log/post_install.log

echo “

Warning!!! This computer system is private and may be accessed only
by authorized users. Data and programs in this system are confidential
and proprietary to the system owner and may not be accessed without
authorization. Unauthorized users or users who exceed their authorized
level of access are subject to disciplinary action, up to and including
termination and are subject to prosecution under state or federal law.
Activity on this computer system is logged.

” > /etc/motd

echo MOTD Login Banner COnfiguration Complete
echo MOTD Login Banner COnfiguration Complete >> /var/log/post_install.log

echo COnfiguring /usr/lib/vmware/hostd/docroot/en/welcomeRes.js banner – Please Wait
echo COnfiguring /usr/lib/vmware/hostd/docroot/en/welcomeRes.js banner >> /var/log/post_install.log

echo Backing up existing WelcomeRes.js
echo Backing up existing WelcomeRes.js >> /var/log/post_install.log
mv /usr/lib/vmware/hostd/docroot/en/welcomeRes.js /usr/lib/vmware/hostd/docroot/en/welcomeRes.js.bak

esxcfg-firewall –allowOutGoing
sleep 20

cd /tmp

lwp-download http://192.168.12.200/welcomeRes.js

cp /tmp/welcomeRes.js /usr/lib/vmware/hostd/docroot/en/welcomeRes.js

esxcfg-firewall –blockOutGoing
sleep 20

echo COnfiguring /usr/lib/vmware/hostd/docroot/en/welcomeRes.js banner Complete
echo COnfiguring /usr/lib/vmware/hostd/docroot/en/welcomeRes.js banner Complete >> /var/log/post_install.log

Last but not least we will install the EMC Naviagent and the HP SIM agent

echo Permorming the installation of the EMC NaviAgentCli
echo Permorming the installation of the EMC NaviAgentCli >> /var/log/post_install.log

echo Downloading the EMC NaviAgentCli – Please Wait
echo Downloading the EMC NaviAgentCli – Please Wait >> /var/log/post_install.log
esxcfg-firewall –allowOutGoing
sleep 20

cd /tmp
lwp-download http://192.168.12.200/naviagentcli-6.19.4.7.0-1.noarch.rpm

esxcfg-firewall –blockOutGoing
sleep 20

echo Installing the EMC NaviAgentCli – Please wait
echo Installing the EMC NaviAgentCli – Please wait >> /var/log/post_install.log
rpm -ivh naviagentcli-6.19.4.7.0-1.noarch.rpm
sleep 20
/etc/init.d/naviagent start

echo Permorming the installation of the EMC NaviAgentCli Complete
echo Permorming the installation of the EMC NaviAgentCli Complete >> /var/log/post_install.log

echo Permorming the installation of the HP SIM Agent ver 7.9.1
echo Permorming the installation of the HP SIM Agent ver 7.9.1 >> /var/log/post_install.log

echo Downloading the HP SIM Agent – Please Wait
echo Downloading the HP SIM Agent – Please Wait >> /var/log/post_install.log
esxcfg-firewall –allowOutGoing
sleep 20

cd /tmp
lwp-download http://192.168.12.200/NYL/hpmgmt-7.9.1-vmware3x.tgz

esxcfg-firewall –blockOutGoing
sleep 20

echo Building HP SIM Answer File – Please wait
echo Building HP SIM Abswer File – Please Wait >> /var/log/post_install.log

echo export CMASILENT=”YES” > /tmp/sidtest_AF.conf
echo export CMANOSTARTINSTALL=”hpasmd” >> /tmp/sidtest_AF.conf
echo export ENABLEHPIMPORT=Y >> /tmp/sidtest.conf
echo export ENABLESNMPSERVICE=Y >> /tmp/sidtest_AF.conf
echo export ENABLESIMCERTPORT=Y >> /tmp/sidtest_AF.conf

echo Installing the HP SIM Agent – Please wait
echo Installing the HP SIM Agent – Please wait >> /var/log/post_install.log
tar xvfz /tmp/hpmgmt-7.9.1-vmware3x.tgz
cd /tmp/hpmgmt/791/
./installvm791.sh –silent –inputfile /tmp/sidtest_AF.conf
sleep 60
echo Installing the HP SIM Agent – Complete
echo Installing the HP SIM Agent – Complete >> /var/log/post_install.log

echo Configuring SNMPd.conf – Please wait
echo Configuring SNMPD.conf – Please wait >> /var/log/post_install.log

echo Making a backup of /etc/snmp/snmpd.conf
echo Making a backup of /etc/snmp/snmpd.conf >> /var/log/post_install.log

mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.bak

echo dlmod cmaX /usr/lib/libcmaX.so > /etc/snmp/snmpd.conf
echo rocommunity hrasmidep 127.0.0.1 >> /etc/snmp/snmpd.conf
echo rocommunity hrasmidep 172.31.44.12 >> /etc/snmp/snmpd.conf
echo rocommunity hrasmidep 172.28.137.14 >> /etc/snmp/snmpd.conf
echo trapcommunity hrasmidep >> /etc/snmp/snmpd.conf
echo trapsink 172.31.44.12 hrasmidep >> /etc/snmp/snmpd.conf
echo trapsink 172.28.137.14 hrasmidep >> /etc/snmp/snmpd.conf
echo syscontact root@localhost >> /etc/snmp/snmpd.conf
echo syslocation CNJ >> /etc/snmp/snmpd.conf
echo dlmod SNMPESX /usr/lib/vmware/snmp/libSNMPESX.so >> /etc/snmp/snmpd.conf

echo Configuring SNMPD.conf – Complete
echo Configuring SNMPD.conf – Complete >> /var/log/post_install.log

echo Permorming the installation of the HP SIM Agent ver 7.9.1 Complete
echo Permorming the installation of the HP SIM Agent ver 7.9.1 Complete >> /var/log/post_install.log

echo Recording Build Script data to host > /etc/build_info
echo Built using Sid_Smith_kickstart_test_script_v1_0.cfg >> /etc/build_info
echo Script Version 1.0 >> /etc/build_info
echo ESX 3.5 Update 3 >> /etc/build_info


######## Installationa and Configuration is finished ######
echo Your server is now installed and configured.  Please review the installation
echo log file at /var/log/post_install.log to verify that there are no errors. Your
echo server will now entered into maintenace mode and will reboot.  Please follow the
echo remaining steps in your automated deployment documentation. 
echo          
echo     Script developed by: Sid Smith
##########
sleep 30
##### Put Server in Maintenance Mode #####
echo Server will now enter maintenance mode
echo Server will now enter maintenance mode >> /var/log/post_install.log
vmware-vim-cmd /hostsvc/maintenance_mode_enter >> /var.log.post_install.log
EOF1
###Make esxcfg.sh eXcutable
chmod +x /tmp/esxcfg.sh

###Backup original rc.local file
cp /etc/rc.d/rc.local /etc/rc.d/rc.local.bak

###Make esxcfg.sh run from rc.local and make rc.local reset itself
cat >> /etc/rc.d/rc.local <<EOF
cd /tmp
/tmp/esxcfg.sh
mv -f /etc/rc.d/rc.local.bak /etc/rc.d/rc.local
shutdown -r now
EOF

It’s important to remember that you should always use a linux compatible editor to edit your script.  If you have been using Notepad remember to open change and save your script in a linux compatible editor before trying to run.  In the next and final part to this blog we will go throuigh deployment options and perform a test deployment of this script.

 I have also included the script as an attachment to this post below:

ESX Automated Deployment Script

*Please excuse some of the formatting in this post.  I am still getting use to the interface and had some issues with the formatting.

VI Toolkit powershell simple script #2 – Create new NFS datastore

This simple little useful script can be used to add a new nfs datastore to all the hosts in an esx cluster.  Alternatively you can modify this and replace get-cluster CLUSTER_NAME with get-datacenter DATACENTER_NAME and add an ISO nfs share to your whole datacenter.

foreach ($ESXhost in get-cluster CLUSTER_NAME| get-vmhost)
                   {
                          New-datastore –nfs –vmhost $ESXhost –name [datastore_name] –path [/remote_path] –nfshost [nfs_server]
                   }

Simply replace CLUSTER_NAME with the name of the cluster you would like to run the script against, replace datastore_name with the name you want the datastore to have, replace remote_path with the nfs path on the nfs server, and nfs_server with the hostname or IP address of the nfs server you are connecting to.

Alternate method:

New-datastore –nfs –vmhost (get-cluster “cluster_name” | get-vmhost) –name [datastore_name] –path[/remote_path] –nfshost [nfs_server]

VI Toolkit powershell simple script #1 – Create new portgroup

This simple little usefull script can be used to create a portgroup at the cluster level.  This enables you to create it once and have it be consistently deployed to all the ESX and/or ESXi hosts in your cluster.

foreach ($ESXhost in get-cluster CLUSTER_NAME| get-vmhost)

                {

                                get-virtualswitch -vmhost $ESXhost -name VSWITCH| new-virtualportgroup -name PORTGROUP_NAME -vlanid VLANID

                }

 

Simply replace CLUSTER_NAME with the name of your cluster, VSWITCH with the name of the vSwitch you would like to create the portgroup on, PORTGROUP_NAME wiht the name of your new portgroup, and VLANID on the VLAN you would like to associate with the portgroup.  If you do not wish to use a VLAN remove the -vlanid VLANID portion of the script.

Hyper-V Failover Clustering, Beyond the Z Drive using the disk GUID

Are you running Hyper-V?  Have you used up all the available drive letters deploying LUN’s for VM’s in your Failover Cluster?  Running out of drive letters? It is fairly easy to get around the 26 drive letter limit in windows when deploying VM’s in a Hyper-V failover cluster configuration.  It is possible to deploy 2000 LUN’s to your Hyper-V cluster environment allowing you to grow your cluster and take advantage of your hardware.

In order to grow beyond the 26 drive letters you will need to install HotFix KB951308.  Once this hot fix is installed you can create shared storage using the drives GUID rather than drive letter or mount point.  Using the drives GUID you can create up to 2000 shared volumes without worrying about running out of identifyers.

What you need to do:

  • Install hotfix KB951308 on all hosts in the Hyper-V Failover Cluster
  • Reboot your Hyper-V hosts
  • Present storage to the server
  • Bring the new storage on-line
  • Initialize the new storage
  • partition and Format the storage, but don’t assign a drive letter or mount point

Using he command mountvol.exe from the command line you can view the GUID for all storage devices attached to your system.  NOTE: You need to run this command form the server that currently owns the storage resource that you want to locate the GUID for.  Alternatively you can locate the GUID by right clicking the storage device in Failover Cluster Manager and selecting properties.

hyperv_drive_guid

Once you have the GUID for the volume you would like to deploy your new Virtual Machine to do the following:

  • Launch the new virtual machine wizard using Hyper-V manager
  • On the “Specify Name and Location” step check the box next to “Store Virtual Machine in a different location” and paste the volume GUID in the location box.
  • On the “Connect Virtual Hard Disk” step choose “Create a Virtual Hard Disk” and in “Location” box paste the GUID for the volume.
  • Complete the creation of your Virtual Machine

Once your Virtual Machine is created you need to launch “Failover Cluster Manager” and create a new “Virtual Machine” Service.  When you create the new Virtual Machine service the disk will automatically be added as a resource for the Virtual Machine”

You can also acheive this using SCVMM 2008.  Make sure to deploy the new VM on the server that currently owns the disk resource.

Automated Deployment of ESX Hosts Part II

This is part II of a multi-part blog. If you haven’t read Part I you can read it here.

The homework from part Iof this blog was to determine what your standard configuration is.  If your having trouble deciding what this should be hopefully today’s session will help with that.  Below you will see all the information that will make up my “standard” build and this will be the information that I use to develop my script.

Sid’s Standard Build

The following information directly relates to the kickstart portion of the script.

Regional Settings:

  • Keyboard layout: US
  • language: US
  • Time Zone UTC America/New_York

Service Console Configuration items:

Partitions:

  • /boot =  100Mb
  • swap = 1600Mb
  • / = 10240Mb
  • /var = 8192Mb
  • /tmp = 4096Mb
  • /opt = 5120Mb
  • /home = 5120Mb
  • vmkcore = 100Mb
  • /vmfs = fill to max

License Server information:

vcenter.sidtest.com (Licenses server is installed on my vCenter Server.

The remaining information is directly related to the post installation portion of the script

Networking:

8 Network Interfaces

vSwitch0 (vmnic0, vmnic2) – Portgroups (Service Console(Vlan 300) & vMotion(vmkernel)(Vlan301))

vswitch1 (vmnic7, vmnic5) – VM Production Portgroups (vlans 2, 15, 150,151,152)

vswitch2 (vmnic4, vmnic6) – DMZ Portgroups (vlans 200, 201, 203)

vSwitch3 (vmnic1, vmnic3) – Backup Networks (vlans 400 & 401)

The two illustrations below show visual diagrams of my network configurations.

Diagram 1

net_design1

Diagram 2

net_design2

NOTE:

When developing your standard build it is always a great idea to manually build one server and map out the network interfaces to vmnics.  It is also very important to use the same hardware and PCI placement for all servers in a cluster.

I have also decided to reject Forged Transmits and MAC address changes on all the vSwitch’s in my environment.

The following is host specific network information for this particular host:

Hostname: vmware1.sidtest.local
Service Console IP Address: 192.168.10.100
Service Console Subnet: 255.255.255.0
Service Console Gateway: 192.168.10.1
VMkernerl IP address: 192.168.12.100
VMkernel Subnet Mask: 255.255.255.0
VMkernel Gateway: 192.168.12.1
DNS Server 1: 192.168.5.20
DNS Server 2: 192.168.5.21
NTP Server 1: 192.168.5. 30
NTP Server 2: 192.168.5.31
NTP Server 3: 192.168.5.32
AD Server 1: 192.168.5.20
AD Server 2: 192.168.5.21

Remaining Build Items

In my build I will be building Active Directory (krb5) user authentication into the service console.  Users will not be allowed to login directly as root.  They will be forced to login using their active directory username and password.  I will be granting the following users login privileges.

ssmith
jbower
cobrian
talmeda

I will also be assigning a grub password to prevent someone from booting up using init 1 and gaining service console access without entering a password.
I will be preventing users from logging into the physical console as root.
I will be setting the following password policy for local user accounts:

  • Maximum password age of 90 days
  • Minimum of 1 day between password changes
  • 14 Day password warning before change required

I will be setting the following MOTD (Message of the Day) and Welcome.js (For web logins) message:

Warning!!! This computer system is private and may be accessed only
by authorized users.  Data and programs in this system are confidential
and proprietary to the system owner and may not be accessed without
authorization. Unauthorized users or users who exceed their authorized
level of access are subject to disciplinary action, up to and including
termination and are subject to prosecution under state or federal law.
Activity on this computer system is logged.

I will be running the following agents in the Service Console:

  • EMC Naviagent
  • HP System Insight Management Agent

I will be allocating 800Mb of Memory to the Service Console.

This completes my ESX Build information.  This is not an all inclusive list of options that can be set or configured as part of an automated installation.  It is possible to configure many other options but for the purpose of this example the preceding standard build will suffice.

Be sure to check back for Part III of this series.  In Part III we will be building our script to support the build that was laid out in this post.  Then later in Part IV we will then go on to demonstrate the options for deploying your script to your ESX Hosts.

VMware Tools status shows as not running after running VMware Consolidated Backup

Yesterday, VMware posted a Knowledgebase Article about VMware Tools appearing to go off line after a VCB snapshot is taken. This issue occurs after applying the ESX350-200901401-SG hotfix. The KB Article also says it can occur “for some time after the initial snapshot” on unpatched hosts, but I have never seen it.

The work-arounds are simple:

  1. restart the mgmt-vmware service (Make sure you don’t have VMs set to auto start)
  2. Log In and log out of the VM, this will cause VMware Tools to kick itself in the pants.
  3. Use the name or UUID lookup method instead of the ipaddr method.

This was originally addressed here.

It is difficult sometimes to get your backup software to use the name lookup method if it does not use a VCB Integration Kit. If you ARE using an integration kit, you can set this in the config.js file:

VM_LOOKUP_METHOD=”name”;

Since most of the “majors” in backup software, like NetBackup, TSM and Networker were originally Unix based, you may be able to find a config file somewhere to set this option.

Using VCB with any backup software

I don’t know how many times I have helped with VCB issues in the past couple of years on the VMTN Forums. It usually falls down to someone not understanding the VM Backup Guide or how VCB works. Honestly, the guide leaves something to be desired. Because of this, I have published a “Proven Practice” guide on VI:OPS to try to clarify things.

<commercial>

VI:OPS is a VMware Forum that dedicates itself to providing information related to operations surrounding a VMware Infrastructure. The “Proven Practice” documents are submitted and reviewed by moderators before they are published. The published documents allow for peers to comment on the documents.

</commercial>

Although VMware provides integration kits for a few different brands of backup software, it does not cover all of the different brands versions. Some vendors have created their own integration kits as well. But not every brand or version is covered. Because of this, I have outlined a generic method for using VCB to back up and recover VMs. Some other things that really needed to be clarified were using VCB in hot-add mode and performing FullVM backups of selected disks. The doc includes screen shots and command sytax examples.  So head over and check out the doc -> Proven Practice: Setting Up VMware Consolidated Backup for any Backup Software.