As I want to get deeper into VMware CLI (vCLI) I deciced to make a summary of the vSphere Command-Line Interface Installation and Scripting Guide. Every chapter will be a separate blog post.
This summary is meant for my documentation but feel free to make use of it.
In this blog post: Running vCLI Commands
Authentication order
- Commandline (–password, –sessionfile, –config)
Path:
Linux: /usr/share/doc/vmware-vcli/apps/session
Windows: c:Program FilesVMwareVMware vSphere CLIPerlappssession
save_session(.pl) –savesessionfile /tmp/vimsession –server s1 –username user1 –password wachtwoord
(.pl is used in Windows)
vicfg-mpath –sessionfile /tm/vimsession –list
- Enviroment variable
Linux: export VI_SERVER=[servernaam]
Windows: set VI_SERVER=[servernaam]
- Configuartion file
vicfg-mpath –config [path_to_config_file] –list
Example:
VI_SERVER = XXX.XXX.XXX.XXX
VI_USERNAME = root
VI_PASSWORD = geheim
VI_PROTOCOL = https
VI_PORTNUMBER = 443
- Current Account (AD)
vicfg-mpath –server [vc_Server] –passthroughauth –passthroughauthpackage “Kerberos” –vihost [esxhost] –list
- Prompt the user for a password
Command not available in lockdown mode (because you can only use vcli command at a vCenter server):
- vicfg-snmp
- vifs
- vicfg-user
- vicfg-cfgbackup
- vihostupdate
- vmkfstools
- esxcli
- vicfg-ipsec
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!
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.
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.
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
During the installation of ZCM10 you’re asked if you want to use a external CA (Certificate Authority) of a internal CA. If you’re using a internal CA it’s important to backup the CA certificate in case you lose the server who is the CA for your ZCM zone. If you lose your CA all the certificates singed by this CA are worthless. That’s ain’t a nice thing in a ZCM enviroment where almost all the communication is encrypted through SSL!
So the first thing to do after the installtion of the first primary ZCM server is to backup the CA. You can accomplish this by entering the command:
zman certificate-authority-export [path and file name]
You’re prompted for a username and password who has the right for exporting the certificate (mostly Administrator) and a passpharse for securing the file.
This passphrase has to have a minimum lenght of 10 carachters. Please store this passphrase in a secure location. If you lose this passphrase the exported CA file is worthless because you need this passpharse to import the certificate.
Importing the certificate is done by entering the command:
zman certificate-authority-import [path and file name]
Again you’re prompted for a username and password who has the right for importing the certificate as the passpharse.
vCLI | Michael December 21, 2010 | 
Comments (0) 