This information was last updated on 29-Jan-2006.
Introduction
This page is designed to aid in designing, setting up, and operating the VMware ESX Server v2.5.x platform. Most of this information has been gathered both during working with the product on different production environments, and (together with students) during the several training sessions delivered on the product.
As this information has been gathered mostly for Trivore's VMware ESX Server class students, the representation might not always be the best possible. Also, some information is pretty purely GNU/Linux oriented. This is intentional, as many technical people are still pretty new to the GNU/Linux stuff running on the Service Console.
These hints and tips do not replace neither the excellent VMware ESX Server manual, nor a decent hands on GNU/Linux knowledge, nor a decent, hands-on-oriented VMware ESX Server classroom education. Any Unix knowledge makes your life a lot easier.
This document is a work in progress as long as v2.5.x is the latest version. Soon after that this document is frozen and a new one should be created. If there is something you might want to see here, or you would otherwise send me feedback, please email us. The maintainer of this information is Kari Mattsson of Trivore Corp.
Planning and documenting the system
This chapter focuses on the planning phase of system setup. It emphasises and reasons the importance of the documentation. More planning oriented material is also in the Storage chapter.
Generally about 4 files make a VM: xxx.vmdk, xxx.vmx, vmware*.log, and nvram. There could be more than one .vmdk file associated to a VM (virtual machine). All files, but the .vmdk file(s) are always in the same (sub)directory. It is most convenient to name that subdirectory xxx.
The older .log files are always deleteable at will. The latest .log file can be deleted when the VM is powered off. A new log file will be created during the next VM power-on. As the log files do not take much disk space, most administrators let them be. If for some reason the current log file vmware.log starts growing too rapidly, you can rename+compress it, or even delete it. It is recommended to execute logrotate daily to check for the logs. More on this later.
The nvram file contains CMOS/BIOS settings for the VM. It the file does not exist, it will be (re)created next time the VM powers up. If any changes were made to the nvram via VM's BIOS setup, do not forget to remake those changes. The most common change to the BIOS settings of a VM is to change the boot device order. The default is floppy, hard drive, CD/DVD. You might want to raise the CD/DVD to higher in the list to be able to boot from there.
In addition to the .vmdk file, a .vmdk.REDO file will exist in the same directory, if non-persistent, undoable, or append disk mode is active for that particular virtual SCSI disk. The .vmdk.REDO file can grow up to several gigabytes. How large it will grow, depends only on what file/disk operations are done on the disk.
It is a good idea to place a brief descriptive xxx.txt file next to the xxx.vmx file to document what this VM is, what is its business purpose, what is the OS version and level, what are the main installed applications, and who is/are responsible for the VM. If you absolutely do not want the .txt file, you could place that same information to the comment lines of the .vmx file. Is the information safe there, is untested.
An alternative to the per VM .txt file approach is a single .txt file which contains information on all the VMs on the server. Okay, you can maintain this document anywhere with any tools, but remember, pure text files are most easily accessed and maintained on the ESX Server by the administrator(s).
Naming a VM, and its files is important. It will be crucial once there are tens (dozens for those of you still using legacy, non-metric systems :-) of VMs. It is a recommended practice to:
A powered on VM can be suspended, much like a laptop or any of the later Windows'. VMware uses the term "Suspend to disk". "Hibernate to disk" might be a more accurate term here. When entering the suspend (hibernate) state, a suspend file will be created. It has a filename extension .vmss. It is very practical to direct the suspend file to the same directory where the VM's operating system .vmdk file is.
If you have two or more VMware ESX Servers, you might want to try suspending a VM on one ESX Server, and resuming it on another. Practical in many cases...
The .vmss file will be a few megabytes larger than the maximum RAM memory allocated to the VM.
This is a realistic example list of files.
Planning is important with ESX. It is especially important with the storage allocated to VMs. Some preliminary questions to answer are: What are the VMs to be installed on ESX Server? What operating systems will be installed? Are they file/print/database/application servers, or what? What kind of storage allocation will be needed? How much storage is initially reserved to a each VM? Are VMs executed on more than one ESX Server at the same time? What are the CPU requirements per VM? What are the network I/O requirements per VM? What are the disk I/O requirements per VM? What are the memory requirements per VM? How much storage is required for suspended VMs? Will non-persistent, undoable or append disk mode be used?
Documenting is another extremely important issue with ESX Server, as these systems easily become extremely complex. Mainframe and Unix style management attitude is really required. Document everything carefully. It will save your day often. The few line .txt file next to .vmx file is especially nice. An example skeleton .txt file follows:
Customer name....................: [Customer name in a multi customer server only] Name of the VM (virtual machine).: [vm###, or hostname/computername] Creation date for this file......: [dd-Mmm-yyyy / creator's name and contacts] Last update of this file.........: [dd-Mmm-yyyy / updater's name and contacts] Business purpose of this VM......: [a short business-related description] Responsible person(s) for this VM: [name, contact (email and/or telephone)] OS name and version in this VM...: [OS name, update level] Installed core application(s)....: [app1, app2, app3]
Storage: partitioning, filesystems, directories, files, etc.
This chapter covers the issues on storage. Some of this material is very planning oriented.
The Service Console on VMware ESX Server is based on RedHat Linux 7.2 / AS 2.1. All the data in this section relates to that fact.
Maximum number of partitions (which can contain data) per SCSI disk (=logical drive on RAID systems) in Linux kernel 2.4.x based systems is 14. The Service Console is based on kernel version 2.4.9. Of these max 15 partitions 3 are primary (1-3), 1 is extended (4), and 11 are logical (5-15). Extended partitions never contain any actual data. It merely acts as a container for the logical partitions.
This 14 data partition (partitions 1-3, and 5-15) limit could force you to create smaller logical drives than you wanted.
It is a nice practice to use primary partitions for non-vmfs filesystems, and logical partitions for vmfs filesystems. Nothing forces you to do that, it is just a choice.
On previous generation IBM, and other brand servers, there is a 10-100 MB System/Service/Diagnostic Partition accessible with [Alt-F1], [F10], or [F11], and it is normally partition /dev/sda4. VMware ESX Server recognises this partition as "Old VMware Core Dump Partition". Usually you do not want to touch this partiton, so leave it alone. VMware will not touch/use it.
SCSI disks are named as /dev/sda (first), /dev/sdb (second), /dev/sdc (third). The first disk is always the boot disk and (practically always) internal to the server. The other disks are usually on an external (usually fibre-connected) disk enclosure. Please note, that many IDE-RAID controllers show up as a SCSI controller, but are currently not supported by VMware ESX Server.
It is strongly recommended to use CD/DVD ISO images, and/or floppy images. Images are very handy for OS and application installations. They are much more reliable and convenient than the actual physical media. Usually some portion of the server internal disk space is reserved for these ISO images. Example commands on how to create these images are given later in this document.
Partitions (dubbed as volumes in VMware ESX Server) formatted as vmfs do not support subdirectories. It is one thing given up for the fast speed of vmfs.
VMware ESX Server v2.x uses version 2 of vmfs dubbed VMFS-2. These volumes (partitions) have 2 possible accessibility settings:
VMFS-2 also allows spanning upto 32 extents. Use spanning only if you really have to. It is not as bad as RAID-0, but you still have a major risk of losing it all if one volume has severe problems/fails. VMFS-1 volumes can be converted to VMFS-2 with vmkfstools command.
When you are creating a .vmdk file to a shared mode volume, the volume might go to read-only mode. You can enable writing to the volume by entering command "vmkfstools --config writable <vmhba-name>".
The virtual SCSI disks (.vmdk files) have four different modes:
Last two modes are invaluable when upgrading or testing the software in a VM, as you can easily revert to the point you enabled that mode. Effectively you can undo any changes to the file system.
It is wise to install VMware ESX Server to the local/internal disks (single RAID-1 SCSI logical drive preferably with a hot-spare). Dual 36 GB drives make plenty of space for mid-size systems. Dual 72 GB is actually today more common and scales up to high-end systems. You might want to go for the higher rotating speed drives to get faster ESX Swap.
Place all the VM-related files (guest OS's configs and disks) to external disks (logical drives) on fibre channel (or similar).
This is where the VMware ESX Server and its Service Console will reside. Partitioning examples are for a system with mirrored 36 GB local/internal drives.
Please note, that the hard drive gigabytes are most often salesman gigabytes (109), not true gigabytes (230). You get less than you thought of.
DeviceName PartType Size MntPoint FStype Remarks /dev/sda1 primary 2500 / ext3 Service Console root. /dev/sda2 extended 32500+ Logical partition container. /dev/sda5 logical 1000 swap swap Service Console swap. /dev/sda6 logical ~14500 /local ext3 See notes below. /dev/sda7 logical 100 vmcore vmcore VMware Core Dump. /dev/sda8 logical ~16000 /vmfs/esxswap vmfs See notes below.
This is really for experienced GNU/Linux administrators only. Use this partitioning scheme instead of the above one on VMware ESX Servers with higher security requirements. For simplicity, the possible System/Service partition is not shown.
This fine-tuning makes it possible to make the Service Console even more secure. You do not want to apply this plan unless you are very familiar with Linux and the Service Console.
DeviceName PartType Size MntPoint FStype Remarks /dev/sda1 primary 100 /boot ext3 Service Console kernel is here. /dev/sda2 primary 500 / ext3 Service Console root. /dev/sda3 extended 34000+ Logical partition container. /dev/sda5 logical 500 /tmp ext3 This is really not much used. /dev/sda6 logical 1000 /var ext3 All the local log files will be here. /dev/sda7 logical 1500 /usr ext3 All standard programs are here. /dev/sda8 logical 50 /usr/local ext3 All server local scripts/programs. /dev/sda9 logical 350 /opt ext3 Optional 3rd party programs. /dev/sda10 logical 1000 swap swap Service Console swap. See note below. /dev/sda11 logical 11000 /local ext3 See notes below. /dev/sda12 logical 100 vmcore vmcore VMware Core Dump. /dev/sda13 logical 16000 /vmfs/esxswap vmfs See notes below.
There are two grand philosophies (schemes) with partitioning the external disk space where VMs reside. You can combine the schemes, if required. Both schemes are presented below:
Please note, that both schemes place VM configuration, and other related small files to a subdirectory under the /vmconf directory.
Scheme A is absolutely the most common, and used about 99 % of the time. It is however possible to mix both schemes at the same time. Some organisations use scheme B for the most important VMs.
This partitioning scheme allows easier growing of .vmdk files and generally is more efficient on disk space usage. It is also a bit riskier. Something could happen to the vmfs partition where all the .vmdk files are. The filesystem could corrupt or something.
Partitioning example for system with 200 GB fibre channel logical drive. The first formatted filesystem is ext3, and the rest are of type vmfs with accesibility set to either public (no operating system cluster VMs exist in the SAN) or shared (operating system VM quorum, and shared disks exist in the same SAN):
/dev/sdb1 primary 200 ext3 fs mounted as /vmconf for VM configs and logs /dev/sdb2 extended ~200000 volume name example name: vmhba2:1:0:2 /dev/sdb5 logical ~160000 public01 /vmfs/public01; accessibility: public /dev/sdb6 logical 39000 shared01 /vmfs/shared01; accessibility: shared
This partitioning scheme needs more preliminary planning. Even then, you might end up having external disk space allocation headache.
It is important to note, that VMware does not endorse this scheme. They recommend placing just .vmdk files to VMFS volumes.
Partitioning example for system with 200 GB fibre channel logical drive; all formatted filesystems are of type vmfs and accesibility is set to either public (only single VMware ESX Server exists in the SAN) or public (also another VMware ESX Server exists in the SAN):
/dev/sdb1 primary 200 ext3 fs mounted as /vmconf for VM configs and logs /dev/sdb2 extended ~200000 volume name example name: vmhba2:1:0:2 /dev/sdb5 logical 10000 vm001 vm001-os.vmdk, 6000 /dev/sdb6 logical 30000 vm002 vm002-os.vmdk, 4000 & vm002-data.vmdk, 20000 /dev/sdb7 logical 10000 vm003 vm003-os.vmdk, 7000 /dev/sdb8 logical 95000 vm004 vm004root.vmdk,10000 & vm004home.vmdk, 75000
On multiple VMware ESX Server configurations with shared fibre channel storage, the following (seemingly a little conflictiong) issues and restrictions apply:
Network: setup and configuration-related issues
Please consider the following issues:
User/group structure on VMware ESX Server Service Console
There are again two schemes you can choose. The first one (A) is the one which is the default. The second one (B) has a quite different approach.
No matter which one you choose, you can always convert to the other one rather easily. Change-over propably takes quite a long time, as it requires powering off all the VMs one-by-one for a short period of time.
Using this scheme, you create one userid for each administrator. The are all placed to one primary group "users". When VMs are created, the creator-administrator gets "rwx" rights to the VM, and the group gets "rx" rights. This means only the creator-administrator can make changes to the VM. Depending on your environment, this could, or could not be what you want.
Using this scheme, you create one userid for each administrator. The are all placed to one primary group "adminsNN". If only one group is required, you could name it "vmadmins". If multiple groups are needed, create groups "admins1", "admins2", etc.
If you define multiple groups for administrators on a large installation, it is a good idea to create one dummy admin account for each group (username "admin001", "admin002", etc.) which only belongs to that group and is used to create new VMs belonging to that administrator group. By doing that, you ensure the access rights are right for the newly created VM.
Actual administrator user accounts always belong to one user group primarily, and optionally to the other user groups. There is more discussion on this at the end of this document (Summary of initial tasks...).
When VMs are created, the creator-administrator gets "rwx" rights to the VM, and the group gets "rx" rights. This means only the creator-administrator can make changes to the VM.
The discussion below presumes you only have one administrator group named "vmadmins".
The difference between the two schemes is made by:
As you can see, the difference between scemes is quite small. It is still very significant. Using scheme B also the "vmadmins" group can make required changes to the VM. Now, depending on your environment, this could, or could not be what you want. The earlier you make your choise between schemes, the easier.
VMware ESX Server tools and documentation
Most, if not all VMware Service Console utilities have a good man page. Enter "man xxx" to get the manual page for command "xxx". Example: man vmkfstools.
VMware ESX Server vmfs partition mount utility is vmware-mount.pl. Parameters -p xxx.vmdk will print out the partition table of the .vmdk file. Parameters xxx.vmdk partition# /mnt/point will mount a particular partition of a .vmdk file to a specified mountpoint in the service console. By default public vmfs partitions are mounted under /vmfs/ directory. You have to mount public and shared partitions manually or you could mount them automatically at every boot by placing correct mount-vmfs lines to the end of /etc/rc.d/rc.local file on the Service Console.
General and very comprehensive vmfs filesystem utility is vmkfstools. It can format, convert, and rename volumes. It can shrink and expand .vmdk files. It can do many many more important things.
VMware ESX Server performance monitoring is installed by default, but it is not activated. It can be activated with command vmkusagectl install. If you want to cleanup the statistics, you will have to uninstall the monitoring service with command vmkusagectl uninstall. You can then clean the database with command vmkusagectl cleandb, and (re)activate/(re)install it again. The excellent monitoring web pages, created with rrdtool, are at address "https://esx-server-name/vmkusage/".
Command esxtop is like the top command, but it shows the VMkernel processes instead.
vdf command displays the amount of free space on different volumes, including VMFS volumes.
ESX netcard utility for locating correct netcard among many netcards is findnic.
Some other commands are: vmfs-ftp, vmkmultipath, vmklogger, vmware-cmd, vm-support.
Some examples on vmware-cmd usage is given below:
All of these tools are properly documented in the VMware ESX Server manuals and/or on VMware's website. The vmware-cmd is documented in Scripting Guide.
Site/server local scripts
It is customary to place local administrator created scripts in Unix/Linux systems to /usr/local. To be more exact, the scripts which are meant to be executed by the root user, should be placed to /usr/local/sbin, while the scripts to be executed by the normal user account level administrators (i.e. non-root), should be placed to /usr/local/bin directory.
Remember to add execute attribute to the scripts with chmod command. It is usually sufficient to enter command like chmod +x /usr/local/bin/SCRIPTNAME, but your corporate security policy might require you to be more exact on to whom you are adding this execute right.
VMware ESX Server-related Linux files and directories
There are a couple of files and directories you should know about. The most important ones are listed below.
VMware ESX Server-related Linux commands
There are several commands you should familiarise yourself with. Most of them and some more are listed here. All of them have an online manual page, which you can read with the command "man command-name".
Install VMware tools to different operating system VMs
These instructions serve as a tiny reminder for administrators on how to do this task. Remember, that this installation has to be done on every VM after an VMware ESX Server upgrade. In the real life, the VMs usually work quite nicely with a downlevel VMware tools, but the combination is not supported, nor recommended.
A hint for VMware: It would make many administrators life a lot easier, if this VMtools upgrade could be done more easily. Think of 2 ESX Servers with 20 VMs on both, and you see what a hassle it can be.
Install VMware tools to GNU/Linux
Many later Linux distributions have a built-in support for VMware's virtual display adapter and have drivers for it. If you have an older distribution, or a custom one, then when you are installing X to the Linux VM, select "Unsupported VGA compatible" as the display adapter.
If you are installing VM to be used as a server, try to do without X.
First you have to open "xterm" or similar CLI. You also could press [Ctrl]+[Alt]+[F2] to switch to TTY2. Login as root there, if not already logged-in. Then follow the instructions.
After selecting in the Remote Console "Settings", and then "VMware Tools Install". Enter the following commands:
cd /tmp mount /dev/cdrom cp /media/cdrom/* /tmp ### See the note below! umount /dev/cdrom tar -xzf vmware-linux-tools.tar.gz cd vmware-tools-distrib ./vmware-install.pl
A note on the cp command above:
On Gentoo CD/DVD is mounted to /mnt/cdrom.
On SUSE it is mounted to /media/cdrom, and/or
/media/dvd.
On RedHat-family of Linuces CD/DVD is mounted to /mnt/cdrom.
On Debian and derivatives, it is mounted to /cdrom.
So change the cp command above accordingly.
...now during the script execution just accept the defaults most of the time by pressing [Enter]. It is when you ar easked about display resolution for X, when you have to stop for a while and think. Select proper resolution, and you are done with the VMware Tools install.
Install VMware tools to Novell Netware
While logged on as admin on the console, do the following to install VMware tools:
Install VMware tools to Microsoft Windows
White you are logged-on as an administrator, do the following to install VMware tools:
The default full installtion also installs VMXnet network adapter driver.
Network: A note on Service Console (Linux) security in production use
This discussion presumes the default high security level is set during the initial VMware ESX Server configuration. In this security level only the following ports are open on the Service Console:
Remember, that sshd is by default always running on the Service Console, so you can always connect to it and do low level management directly to the Service Console files. An example of this kind of management is when the MUI stops responding. Just login using your account via ssh, and enter the following command to restart the webserver responsible for the MUI: su -c "/etc/init.d/httpd.vmware restart". You normally need the root's password to complete this task. You could (should!) also use sudo/visudo to make thing even easier.
Additional tasks to increase security
This is mainly a list of things to do. Not all of this applies to all installations.
Working sample logrotate scripts
The file below should be saved as /etc/logrotate.d/messages, and the rotating will start.
# logrotate script for the master log file
#
/var/log/messages {
size 50M
monthly
compress
dateext
rotate 20
notifempty
}
The file below should be saved as /etc/logrotate.d/vmware_log, and the rotating of all per VM log files will start. Rotating of these log files has never been necessary in any server I have heard of.
# logrotate script for per VM vmware.log files
#
/vmconf/*/vmware.log {
size 1M
compress
dateext
rotate 2
notifempty
}
Backup VMs to other host with sshd on the Service Console
Please note, that from the "other host", where you have backed up the VMs, the VMs can be backed up to tape, etc.
As you cannot copy the .vmdk files while the VM is powered on, it is probable, that the time windows for executing this script on a production server is too small. That is why this script is more a proof-of-concept.
This discussion presumes the following:
#!/bin/bash
# Fetch files related to VM $1 from VMware ESX Server using userid 'backup'.
export vmname=$1
mkdir /backup/esx01.trivore.com/${vmname} 2>/dev/null
cd /backup/esx01.trivore.com/${vmname}
scp -p backup@esx01.trivore.com:/vmfs/${vmname}/* .
Name the above script "/usr/local/sbin/esx-vm-backup", and execute it with parameter "vm001", or any other VM name. Example command: /usr/local/sbin/esx-vm-backup vm001
Task: Do a full backup of the Service Console
This backup, to ensure all files make it to the backup, should be done in runlevel 1, i.e. in single user state. In that runlevel, network, and vmfs volumes are all unavailable. Also the ESX Server is not up in runlevel 1.
The way to enter single-user Linux mode is:
It is presumed here, that a sufficiently large partition exists, and is mounted to directory /local. If not, then some adaptations has to be made. Two working example commands are below to make a compressed tar backup file:
tar -czf /local/service-console-2.5.3-`date -I`.tar.gz \ --exclude /proc --exclude /local --exclude /vmconf / tar -cjf /local/service-console-`head -2 /etc/issue|tail -1|cut -d" " -f4`-`date -I`.tar.bz2 \ --exclude /proc --exclude /local --exclude /vmconf /
...where 2.5.3 is the VMware ESX Server version number, and `date -I` is replaced with an ISO standard format of current date, such as "2005-10-13". Second example will fetch the VMware ESX Server version number automatically. Only the descending single quotes shown in the example do work.
Normal size for the backup file is about 200 MB, and it is created in two or three minutes. The "z" in the first example uses gzip for bigger backup file. The "j" in the second example uses bzip2 for smaller backup file. For compression gzip is faster than bzip2. For decompression, the speed is roughly the same.
If you want to time the backup, or any other command, just begin the whole command-line with an additional command "time ".
It is also recommended to save a current copy of /etc/fstab, your current mounts, and current partitioning. These are all very helpful items in a crisis situation. Just enter the following commands to save this information to /local directory.
cp /etc/fstab /local/current_etc_fstab mount > /local/current_mount vdf > /local/current_vdf fdisk -l > /local/current_fdisk-l
As the above information does not change very often, it is a very doog idea to have the above 4 files printed out next to the server.
For help in restoration you have to contact someone with enough Linux knowledge, as the scenarios, options, and choices on what/how to do it vary so much. Trivore Corp. will obviously be happy to help you - for a moderate fee.
Task: Do a full restore of the Service Console after a catastrofic failure
Too numerous requests have arrived to include this information, so here it is.
Full VMware ESX Server Service Console restore is actually rather simple. Below are the required steps. Note, that depending on how badly corrupted your system is, you might be able to skip some of the steps.
The above task can be done in less than 15 minutes on just about any hardware. As you may have noticed, some of the large iron boots for a long time.
Commands (script!) to fix user rights on VM directories and files
Please note, that these commands require, that you have implemented userid plan B.
These commands make a script you should execute regularly/occasionally as a root to make sure you have the proper rights on VM directories and files.
#!/bin/bash
#
# I am /usr/local/sbin/vmrights.
#
vmconf=/vmconf # Check the value on the left!
admingrp1=vmadmins # Check the value on the left!
chgrp -R $admingrp1 $vmconf /vmfs
chmod 0775 $vmconf ${vmconf}/* /vmfs /vmfs/*
chmod 0660 /vmfs/*/*.dsk /vmfs/*/*.vmdk
chmod 0770 ${vmconf}/*/*.cfg ${vmconf}/*/*.vmx
chmod 0660 ${vmconf}/*/nvram ${vmconf}/*/vmware*.log
#
# Note: You will get an error message on ESX swap file on the 'chgrp'
# line above. Add '2> /dev/null' to the line to avoid it.
# Note: This script is for single VM admin group setups only.
# Note: If you are using group other than 'vmadmins', change the line
# above accordingly. You may want to store configs for different
# admin groups in different directories (/vmconf1, /vmconf2, etc.).
# Note: .cfg and .dsk are for old VMs created during v1.5 era. You can
# safely remove those references if you don't have such files.
# Note: If you have one or more VMs, where all the files are in one
# single VMFS volume (External disk space partitioning scheme B),
# then you are required to make some changes to this script.
If you make this a script, then please store it (as a root) to /usr/local/sbin as 'vmrights', or similar. Also give root executable rights to this script for easy execution. Example command is given below:
chmod u+x /usr/local/sbin/vmrights
Remember, that only root can really execute this script/these commands.
It might be a good idea to execute this script automatically to fix the file permissions. That way all administrators can do what they need to do. To make the script execute either daily, or hourly, execute only one of the commands below, not all of them:
ln -s /usr/local/sbin/vmrights /etc/cron.monthly ln -s /usr/local/sbin/vmrights /etc/cron.weekly ln -s /usr/local/sbin/vmrights /etc/cron.daily ln -s /usr/local/sbin/vmrights /etc/cron.hourly
In many organisations this script is only executed right after a new VM has been created before powering it on for the first time. It really should be sufficient.
Summary of initial tasks to be done just after installation (...or sometime later :-)
These command could be combined to a script to be executed. Because these are one-off commands, many admins just copy-paste these to a VMware ESX Server Service Condsole ssh session for immediate execution.
##### SECTION: User and group management. # ### CASE 1: You need only one VM admin group. groupadd -g 7000 vmadmins useradd -g 7000 admin001 ; passwd admin001 # ### CASE 2: You need 3 different VM admin groups. # groupadd -g 7001 admins1 groupadd -g 7002 admins2 groupadd -g 7003 admins3 # # Create all the VM admin users similarly to the sample below. useradd -g 7001 person1 ; passwd person1 # # OPTIONAL: # These generic admins are ONLY used for creating the VMs # belonging to a particular admins group (admins1, admins2, ..) useradd -g 7001 admin001 ; passwd admin001 useradd -g 7002 admin002 ; passwd admin002 useradd -g 7003 admin003 ; passwd admin003 # # OPTIONAL: # Create an admin beloging primarily to one group, and # secondarily to another group. Set pasword. useradd -g 7001 -G 7003 personA ; passwd personA # # OPTIONAL: # Create an admin beloging primarily to one group only. # Set pasword. useradd -g 7002 person2 ; passwd person2 # # The group numbers 7000+ are arbitrary. Any unique number will do. # All numbers between 1000 and 65533 are safe here. ##### SECTION: A mandatory and an optional system change. # # Make the important changes below: # - change 'umask 022' to 'umask 002' to everyone (after the 'else' line). # - change '\W' in PS1 environment variable to '\w' to enable seeing full path all the time. # The first one is mandatory if you are using user acoount scheme B, the second one is optional. # nano -w /etc/bashrc ##### SECTION: Keep correct time on the system. # # Tasks below: Keep correct time on the server system. # Configure ntpd, make it autostart, and start it now. # Replace 'fi' with your own countrycode, or 'europe', or goto www.pool.ntp.org! # Instead of 'europe', use 'asia', or another continent. # If in doubt, use four times 'pool.ntp.org' below. It is safe and works! echo "# " >> /etc/ntp.conf echo "# It is good idea to define at least 4 [*.]pool.ntp.org servers." >> /etc/ntp.conf echo "server fi.pool.ntp.org" >> /etc/ntp.conf echo "server europe.pool.ntp.org" >> /etc/ntp.conf echo "server europe.pool.ntp.org" >> /etc/ntp.conf echo "server pool.ntp.org" >> /etc/ntp.conf chkconfig --add ntpd /etc/init.d/ntpd restart ##### SECTION: Define command aliases and set correct keyboard. # # Create some handy aliases and activate them immediately. echo "alias nano='nano -w'" >> /etc/profile echo "alias cd..='cd ..'" >> /etc/profile echo "alias ..='cd ..'" >> /etc/profile source /etc/profile # Select your keyboard. The default is US. setup ##### SECTION: Optional Service Console system logging changes. # # Three lines below: we want to see several more severe log entries on TTYs too. echo "# " >> /etc/syslog.conf echo "# Comment-out 3 lines below to protect tty10-tty12" >> /etc/syslog.conf echo "*.crit /dev/tty12" >> /etc/syslog.conf echo "*.=err /dev/tty11" >> /etc/syslog.conf echo "*.=warning /dev/tty10" >> /etc/syslog.conf # The line below: restart system logging daemon to activate above changes. /etc/init.d/syslog restart ##### SECTION: Creating/formatting/mounting partition for VM configs. # # Note: The tasks below are usually done at the installation phase with VMware # ESX Server 2.1+, so you can usually skip these. # # Enter the following command to start non-boot disk partitioning: fdisk /dev/sdb # ! ensure /dev/sdb is the proper disk to store VMs for you # - create 200 MB primary partition 'sdb1' (new, primary, 1) # - create rest-of-drive extended partition 'sdb2' (new, extended, 2) # - write-out the partition table, reboot server if you get errors on writing # - then you can enter the following commands finalise the task: fdisk /dev/sdb mke2fs -j /dev/sdb1 mkdir /vmconf echo "/dev/sdb1 /vmconf ext3 defaults 0 2" >>/etc/fstab mount -a # Now you want to use the Management UI to create/format/label VMFS volumes for VMs. # Sometimes the MUI requires a server restart to recognise new partitions, # such as the /dev/sdb1 created just above.
Miscellaneous links to external sites and VMware ESX Server-related utilities
This list is obviously permanently a work in progress. Please note, that especially the VMware's links below contain lots of links to different documents and discussion forums.
If you think you have a useful addition to the above list, please mail me a link.
A hint for printing this document: Set the left and right margins to as narrow as possible on your browser. An alternative hint is to print this document in landscape form, not as portrait. Fact: Only landscape printing gets you everything on paper.
© 2003-2006 Trivore® Corp.