New VMware vSphere 4.1 courses. Need help for content!

Now that VMware has annouced that ESXi will be the only version of vSphere to be continued, It is  time to update the VMware vSphere courses that I give for Ictivity Training to ESXi 4.1. We already have a Practical Administration course and a Advanced Administration course based on VMware vSphere 4.0. Due to many requests we want to add a Advanced Security course to this list.

The Practical Administration course is meant for System Administrator who have to manage a VMware vSphere environment on a daily basis. Most of the task will be Virtual Machine related.
The book we want to use is: Mastering VMware vSphere by Scott Lowe
Content of this 3 day course is:

  • Introduction to VMware vSphere 4.1 and concepts
  • Configuration of VMware vSphere
  • Installation of the vSphere Client
  • Installation of vCenter
  • Host Profiles
  • Installation and configuration of a Virtual Machine
  • Templates and Clones
  • P2V (VMware Converter)
  • Snapshots
  • vCenter Webaccess
  • VMFS management
  • Storage Concepts (NFS, iSCSI, FC)
  • Virtual Switches
  • Port Groups
  • Load balancing and fault Tolerance
  • Roles and Permissions
  • Alarms
  • Tasks and Events
  • VMware Vmotion
  • Storage Vmotion
  • Concept of VMware clustering
  • Backup concepts

The Advanced Administration course is for System Administrator of a larger vSphere Enviroment has have to monitor and change the vSphere hosts, Storage and Networking.
The book we want to use is: VMware vSphere 4.1 HA and DRS Technical deepdive by Duncan Epping and Frank Denneman
Content of this 2 day course is:

  • Advance Networking
  • Distributed Switches
  • VMXnet Generation 3
  • (Private) Vlans
  • Pluggable Storage Architecture (PSA)
  • VMDirectPath
  • vCenter Linked Mode
  • HA best practice
  • DRS best practice
  • FT best practice
  • DPM best practice
  • vCenter Update Manager
  • Scripted Installation
  • VMware Management Assistant
  • VMWare Command Line Interface
  • RESXTOP
  • Recourse Pools

The new Advanced Security course is for System Administrators have have to monitor and mange a vSphere enviroment where security has a priority (Banks, Ensurance companies, etc).
The book we want to use is: I don’t have a clue!
Content of this 1 day course is:

  • VMware vSphere ESXi lockdown
  • Securing Virtual Machines
  • Securing Storage Networks
  • Securing vCenter
  • Securing virtual Networks
  • Authentications through Active Directory
  • Logging with Syslog
  • VMware VMsafe
  • Certificates

We find it very important that the content of these courses match real life of our work. There for I want to asked you what you think of the training content and books we want to use? Please provide feedback through the comment section. Thanks!

Creating a PXE boot for ESXi 4.1 with a kickstart installation

For the VMware course I teach for Ictivity Training VMware ESXi server have to be deployed on a regular basis. In the passed I have made a kickstart installation for ESX witch could be used on a USB stick during the boot of the DVD. Now that we’re upgrading the VMware courses to vSphere ESXi 4.1 I wanted to create a PXE boot environment witch could be used to install different ESXi 4.1 servers.
Because I’m a Novell/VMware guy I wanted to create a SLES11 virtual machine for the PXE boot environment that runs on VMware vSphere or VMware Workstation.

I’m assuming that you all know how to create a virtual machine and how to install SLES 11 inside this virtual machine with the VMware tools.
During installation make sure you select the following packages:

  • DHCP Server
  • TFTP Server
  • Apache
  • syslinux

I’m also assuming you have downloaded the VMware ESXi 4.1 iso file from the VMware website and that this is located in the /root directory.

For testing purpose, we’re not going to enable the kickstart installation during the test of PXE boot. This is added later.

PXE Setup

First step is to configure the DHCP server. Here is my configuration file.

option domain-name “training.local”;
option domain-name-servers 172.16.1.100;
option routers 172.16.1.1;
default-lease-time 14400;
ddns-update-style none;
authoritative ;
filename “pxelinux.0”;
subnet 172.16.0.0 netmask 255.255.0.0 {
range 172.16.1.200 172.16.1.220;
default-lease-time 14400;
max-lease-time 172800;
}

This configuration file gives a lease in the range 172.16.1.200 – 172.16.1.220 with a subnetmask of 255.255.0.0, a default gateway 172.16.1.1 and a domain name server 172.16.1.100. The option filename “pxelinux.0” will tell the PXE client to look on this server with the tftp protocol for a fill called pxelinux.0. We’re going to provide this file later on.
Make sure that the DHCP server is started at boot time.

Second step is to configure the TFTP server.
In yast under Network Services select TFTP server. Yast will tell you that the default location for the TFTP files will be /tftpboot. In my case I move this location to /srv/tftp because I think this is a better location. Make sure that the TFTP server is started at boot time.

Third step is to provide the necessary file for the PXE boot.

  • Copy the /usr/share/syslinux/pxelinux.0 to /srv/tftp
  • Create a directory /srv/tftp/pxelinux.cfg
  • In this directory create a file called default and open this file in your default text editor. Below is my file.
  • MENU TITLE Ictivity Training VMware ESXi installation menu
    PROMPT 1 #display the boot: option during boot
    TIMEOUT 100 # a timeout value of 10 second after this de DEFAULT will be started unless another option is entered during boot
    DEFAULT localboot #default is the option localboot

    SAY Welcom to the Ictivity Training VMware ESXi installation menu #Some text messages
    SAY Type esxinstall to start the VMware ESXi installation, do nothing local boot will happen. #Some text messages

    LABEL localboot
    localboot 0x80

    LABEL esxinstall
    kernel vmware/esxi4.1/mboot.c32
    append vmware/esxi4.1/vmkboot.gz — vmware/esxi4.1/vmkernel.gz — vmware/esxi4.1/sys.vgz — vmware/esxi4.1/cim.vgz — vmware/esxi4.1/ienviron.vgz — vmware/esxi4.1/install.vgz — vmware/esxi4.1/image.tgz

  • This file is read during the PXE boot. We will provide the files in vmware/esxi4.1/* in a later step.

Foured step is to provide the ESXi file for installation.

  • Mount the iso file that you have save in the /root directory with the command:

    mount -o loop /root/VMware-VMvisor-Installer-4.1.0-260247.x86_64.iso /mnt/iso

    This assumes that you have a directory called /mnt/iso!

  • Create a directory /srv/tftp/vmware/esxi4.1/
  • Give the command:
    cp -R /mnt/iso /srv/tftp/vmware/esxi4.1/

Now we’re ready to test the PXE boot.

Kickstart

Now PXE booting is working we can create a kickstart script file (normally called ks.cfg). This file will be located in the default documentroot of Apache (/srv/www/htdocs).

  • Create a file called ks.cfg, place this file in /srv/www/htdocs and open this file with you favorite text editor.
  • Below is my ks.cfg file. This is not a complex file but for my purpose (setting-up the classroom environment) this does the trick.

    #Kickstart script file for host vsphere1
    #Created by: M. Wilmsen/WilmsenIT
    #Date: 8/12/2010

    accepteula
    rootpw yourpassword
    autopart –firstdisk –overwritevmfs
    install url http://172.16.1.100/vmware
    network –bootproto=static –ip=172.16.1.25 –gateway=172.16.1.1 –nameserver=172.16.1.100 –netmask=255.255.0.0 –hostname=vsphere1.training.local –addvmportgroup=0

  • In the documentroot of Apache the installation files of ESXi 4.1 have to be available. The file will be place in the directory vmware. Ofcourse you can copy the files from the iso file again to the vmware directory. But we did this already for the PXE setup. So rather than copying the files again we make a symbolic link to /srv/tftp/vmware/esxi4.1/

    ln -s /srv/ftfp/vmware/esxi4.1/ vmware

  • Because we’re using a symbolic link and that the ks.cfg file is located on the documentroot of Apache we have to enable the options Indexes and FollowSymLinks in the /etc/apache2/default-server.conf file.

    <Directory “/srv/www/htdocs”>
    # Possible values for the Options directive are “None”, “All”,
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that “MultiViews” must be named *explicitly* — “Options All”
    # doesn’t give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs-2.2/mod/core.html#options
    # for more information.
    Options Indexes FollowSymLinks
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be “All”, “None”, or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    AllowOverride None
    # Controls who can get stuff from this server.
    Order allow,deny
    Allow from all
    </Directory>

  • The final step is to modify the default PXE configuration file in order to tell the ESXi setup to make use of our ks.cfg file. To do this open the /srv/tftp/pxelinux.cfg/default in you favorite text editor and add ks=http://172.16.1.100/ks.cfg after the vmkboot.gz option. Your default file will look like this:

    menu title Ictivity Training VMware ESXi installation menu
    PROMPT 1
    TIMEOUT 100
    DEFAULT localboot

    SAY Welcom to the Ictivity Training VMware ESXi installation menu
    SAY Type the servername to start the VMware ESXi installation, do nothing local boot will happen.
    SAY Valid servernames are: vsphere1

    LABEL localboot
    localboot 0x80

    LABEL vsphere1
    kernel vmware/esxi4.1/mboot.c32
    append vmware/esxi4.1/vmkboot.gz ks=http://172.16.1.100/ks.cfg — vmware/esxi4.1/vmkernel.gz — vmware/esxi4.1/sys.vgz4.1/image.tgz

And there you go. Now we can use PXE boot to install our ESXi 4.1 servers. Of course you can create a more advanced ks.cfg file but that’s up to you.

Novell Data Synchronizer Mobility Pack – Update 2

Somenhow I missed this announcement, but as of 1 december Novell released Novell Data Synchronizer Mobility Pack – Update 2. This update has some new features as well as some bug fixes.
You can get the update through the Novell Customer Center or Patch Finder.

New Authentication Source: You can now choose to use GroupWise as your authentication authority. In addition to LDAP, the administrator can choose to use the GroupWise system to authenticate devices into Mobility.

Easy Upgrade: The administrator can now seamlessly update their Mobility solution from one version to the next without having to ‘rip and replace’. This solution will preserve all of their settings and customizations that they had previously configured.

Block a User or Device: Sometimes there are rogue users or devices that are causing havoc on your system or post office. Now you can easily identify those users/devices and easily block them in order to restore stability and reliability. Even if you have a user with multiple devices – you can block one without effecting other devices for that user or other users on the system.

Monitoring: New capabilities have been added for the administrator to easily monitor the health of the POA’s and event queue within their Mobility implementation. Easily see

•Status of the GW Connector and the POA’s talking with the connector
•Pending events to the sync engine and from the sync engine
The monitoring UI now has all of this capability:

•UI on the GroupWise Connector showing the status of the GW Connector and the queue.
•Functionality to query the GW Connector status. Responses should be on a green, yellow, red status basis.
◦Green: The connection to the POA is good and the connector is up to date in processing events from the sync engine.
◦Yellow: The GW Connector is behind processing sync engine events for data being sent to the POA.
◦Red: The connection to the POA is down.
•Queues: There are two queues.
◦The events coming from the sync engine that need to be processed and if needed sent on to the specific POA.
◦The tasks to process the GroupWise event notifications from the various POA’s.
Nightly Maintenance: Nightly maintenance is required to clean-up user folders that are not accessed by a device. Up to this point, folders like the junk mail folder could grow unchecked. A user would need to click on the folder to force the cleanup. Additional clean-up tasks will be added in the future as needed. The infrastructure for this capability is now complete and the clean-up of user folders was the first maintenance task. By default, this maintenance will run from midnight until 6am. The start time is configurable. The process walks through each user’s data and looks for items in folders that have ‘expired’. Expired means that the device no longer needs this data and it can be removed from the Connector database.

Restricted Attachments: If an attachment did not make it to the device because of size limitations or other failures, a notification is now available on the device that notifies the user that the attachment did not sync and why.

And the bug fixes:

•Appointments not synching to sub-calendars: If your sub-calendar folder was under your ‘Documents’ folder, synchronization was not happening.
•Contacts created or edited on Device not Synching: Seemed to be happening a lot on Droid devices. Fixed a few defects related to this.
•Contacts created on Droid, not Syncing: Problem if you have duplicate Frequent Contact books.
•Battery life improved when Push Enabled
•Events dropped, if ‘add’ event does not arrive first
•Device Event Monitor could Hang, affect sending messages from Device
•Sub Calendar events not updating on device in real-time