Thanks to a tweet from vConsult I learned that a new vCenter and vSphere update was released.

As always test before deployment!!

What's New

The following information describes some of the enhancements available in this release of VMware ESXi:

• Enablement of Trusted Execution Technology (TXT) — ESXi 4.1 Update 1 can be configured to boot with Intel Trusted Execution Technology (TXT). This boot option can protect ESXi in some cases where system binaries are corrupted or have been tampered with. TXT is currently available on Intel Xeon processor 5600 series servers. For more information, see KB 1033811.
• Improvement in scalability — ESXi 4.1 Update 1 supports up to 160 logical processors.
• Support for additional guest operating systems — ESXi 4.1 Update 1 provides support for RHEL 6, RHEL 5.6, SLES 11 SP1 for VMware, Ubuntu 10.10, and Solaris 10 Update 9 guest operating systems. For a complete list of guest operating systems supported in this release, see the VMware Compatibility Guide.
• Inclusion of additional drivers — ESXi 4.1 Update 1 includes the 3ware SCSI 2.26.08.036vm40 and Neterion vxge 2.0.28.21239-p3.0.1.2 drivers. For earlier releases, these drivers are only available as separate downloads.

Resolved Issues – In addition, this release delivers a number of bug fixes that are documented in the Resolved Issues section.

What's New

This release of VMware vCenter Server 4.1 Update 1 offers the following improvements:

• Additional Guest Operating System Customization Support: vCenter Server now supports customization of the following guest operating systems:
  • Windows 7 SP1 (x32 and x64)
  • Windows Server 2008 R2 SP1 (x32 and x64)
  • RHEL 6.0 (x32 and x64)
  • RHEL5.5 (x32 and x64)
• Additional vCenter Server Database Support: vCenter Server now supports the following databases:
  • Microsoft SQL Server 2008 R2
  • Microsoft SQL Server 2005 SP3
  • Oracle 11g Standard/Enterprise Release 2, 11.2.0.1.0 or later,  (x32 and x64)
  • IBM DB2 9.7.2 Express C (x32 and x64)
  • IBM DB2 9.7.2 Enterprise (x32 and x64)
    For more information about using IBM DB2 - 9.7.2 database with vCenter Server 4.1 Update 1, see KB 1033201.
• Resolved Issues: In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.

I was listening to an very interesting presentation this evening from Olivier Cremel, Principal Engineer
ESXi Internals: Better Understanding for Better Management and Troubleshooting

The ESXi Architecture document actually states that the memory footprint of the hypervisor is 32mb

Eric Gray, also put up a post regarding the hypervisor footprint - again 32mb

The hypervisor is loaded into memory into a RAMDISK. But where exactly can you see the size of the RAMDISK in which the hypervisor runs, and is it actually 32mb?

Two places:

1. In the System Resource Allocation settings for your ESXi host.

Here you can see that the size of 32MB is reserved - so that it will always be available - but it is also limited at 32MB so that it does not grow larger than the specified size.

2. In the ESXi host itself.

As you can see from the output below

~ # vdf --help
vdf: invalid option -- -
Gather stats about visorfs
visorfsdf [filepath]
   -h       multiple instead of blocks
   -p       resource pool view

As you can see from the output above the MAINSYS partition is the set 32MB.

Of course because all the entities above are resource pools, they can be configured to your needs - but they should only be done with specific guidance from VMware support.

A nice bit of info..

*****Update June 11, 2012******

The new version is available here

*****************************

• Updated to the latest PowerPoint Icons and Images - 3Q10
• Added new items to Stencils (30+)
• All graphics now have connection points - which will make work easier.

Box Shots	Icons	Products

As was posted on the new KB article 1029925 the vSphere Client is no longer packaged with current builds of ESX and ESXi. However it is packaged with vCenter, so you can still get it from the web interface of your vCenter server.

Since they have posted a direct URL to the download I decided to wrap this in a PowerShell script
Get-vSphereClient.

Function Get-vSphereClient {
<#
.SYNOPSIS
 Downloads the vsphere 4.1 Build 258902 Client
.DESCRIPTION
 As was posted on the new KB article 1029925 the vSphere Client is no longer 
 packaged with builds of ESX and ESXi. This function will download the vSphere 
 client from VMware's site
.NOTES
 Author: Maish Saidel-Keesing
.PARAMETER Url
 The url for the .exe file
.PARAMETER Path
 The location the file will be saved
.EXAMPLE
 PS> Get-vSphereClient -url http://vsphereclient.vmware.com/vsphereclient/2/5/8/9/0/2/VMware-viclient-all-4.1.0-258902.exe -path c:\temp\viclient.exe 
#>

param (
$url="http://vsphereclient.vmware.com/vsphereclient/2/5/8/9/0/2/VMware-viclient-all-4.1.0-258902.exe", 
$path="c:\temp\VMware-viclient-all-4.1.0-258902.exe" 
)

##Create Web Client 
$client = new-object System.Net.WebClient
$client.DownloadFile($url,$path)
}

Hope you can make use of this.

Jase McCarty posted an article on on how to change this behavior on his blog a few months back as well.

So first post about the free Hypervisor under its new name.

I wrote an article regarding the process of upgrading from ESXi 3.5 to ESXi 4.0.

Well I am happy to announce that this has changed - again! Have you tried to find the VMware vSphere Host Update Utility? It was never downloadable - it was part of the vSphere Client which was bundled with your ESXi Installation.(by the way that has also been removed from the installation and is not a separate download as well.

What once was

Is now..

The reason that the download is actually almost 160MB larger with less inside is a mystery to me (I guess the multiple languages now built in - make it a lot larger). But there is no Host Update utility any more.

The general consensus is that that VMware are pushing for Central Management - which means you need to use Update Manager - which is only part of the vCenter Package.

If you still want to update your hosts you will have to revert to a bit of command-line work.

The solution to this in the Upgrade Guide.

What you will need is:

1. A Scratch Partition on your ESXi host
   
   You must configure a scratch partition and reboot the host before proceeding with the upgrade.
   You can configure a scratch partition for a host under the Software Advanced Settings in the Configuration tab of the vSphere Client.
   
   What is the Scratch Partition?
   
   During the autoconfiguration phase in the Host installation process, a 4GB VFAT scratch partition is created if the partition is not present on another disk. When ESXi boots, the system tries to find a suitable partition on a local disk to create a scratch partition. The scratch partition is not required. It is used to store vm-support output, which you need when you create a support bundle. If the scratch partition is not present, vm-support output is stored in a ramdisk. This might be problematic in low-memory situations, but is not critical.
   
   For ESXi Installable, the partition is created during installation and is thus selected. VMware recommends that you leave it unchanged.
   
2. vSphere CLI - Download Here
   
   Download the tool - For Windows or Linux and install on your workstation.
   
3. Download the Upgrade Package for 4.0 to 4.1 or the Upgrade Package from 3.5 to 4.1 
   
4. Power off your VM's and put the host into maintenance mode
   
5. Change your current directory to C:\Program Files\VMware\VMware vSphere CLI\bin
   
6. From the vSphere CLI prompt

vihostupdate.pl --server host name or IP address -i -b location of the ESXi upgrade ZIP bundle -B ESXi410-GA

So in my case

vihostupdate.pl --server msaidelk-esx -i -b c:\temp\upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip -B ESXi410-GA

You can of course do the same thing with ESX Updates as well

vihostupdate.pl --server host name or IP address -i -b location of the ESXi upgrade ZIP bundle -B ESXi410-GA-esxupdate

A reboot of the host is necessary thereafter.

Happy Upgrading!!

**Update 28-08-2010**

Updated the syntax to include the .pl extension to the command and added Step 5.

The previous post about what was new in vSphere 4.1 was a general overview with some slide shots. For all ye of little faith thinking that I was only going to post those screenshots with no details Nuh-Uh! 
I prefer to lay down the basics with screen shots - and then go into the details. I mean you do have to cater for all spectrums of the public from basic to advanced.

So without further a due - let's go into how you can add you ESX/i server into the domain.

But why would you?

Well actually there is a very simple reason - Security. One of the biggest problems it providing a single mechanism to authenticate yourself with the same credentials to all components of your infrastructure. With vCenter it is easy - since it is a Domain Member - all authentication is done through active directory. But going directly into the ESXi host - that is a different story all together you will have either authenticate with Linux credentials - or configure the authentication to be done by active directory - but for that you need a valid Linux user on the ESXi box.

(** Small note - since the future version of ESX will only be ESXi I have decided - that I will be using ESXi exclusively in my posts - unless the issue is directly related to the full ESX version)

There are 4 ways of doing this

1. ESXi Host directly
2. Host Profiles
3. CLI
4. Script

Before starting you need to make sure of a few things

You have correct time synchronization with between your ESX host and the Domain controllers - this is a must. Kerberos is extremely picky when time difference off.

You have proper DNS resolution from the ESX Host, and that the name servers are correct.

Also your ESX host has to have a FQDN - for example:

Hostname: esx1
Domain: maishsk.local
FQDN: esx1.maishsk.local

On the ESXi Host

Log into your host directly - NOT through the vCenter. The documentation says

I have found that if you do this on the vCenter server - the Properties option is grayed out. and you cannot make the change.

Configuration Tab -> Authentication Services-> Properties

Enter domain name (in one of two ways) maishsk.local (Default computer location) or maishsk.local/Computers/ESX (for putting the computer account in the ESXi OU under the computers container)

Click Join Domain - and you will be asked for domain credentials - this user has to have permissions to add computers to the domain. Format is either administrator@maishsk.local or MAISHSK\administrator or just plain administrator

Once that is done - you can see on the Active Directory Users and Computer Console that you now have a new computer account.

To allow the the user/group access to the ESXi host your will have to define the permissions.at the appropriate level.

In the case I gave the Domain Admins full access to the Host

Permissions -> Add Permission -> Administrators ->Add

From the Server field choose your domain and search for your user/group (reminds anyone of vCenter?)

The user can now login with their domain credentials

*** Update ***

I would like to also point out the what Raphael Schitz posted on his blog regarding the ESX Admins group and how this group automatically has access to the host just added to the domain. Thanks for pointing this out

By default, the ESX host assigns the Administrator role to the “ ESX Admins ” group. By default, the ESX host assigns the Administrator role to the "ESX Admins" group. If the group does not exist when the host joins the domain, the host will not assign the role. If the group does not exist When the host joins the domain, the host Will not assign the role. In this case, you must create the “ESX Admins” group in the Active Directory. The host will periodically check the domain controller for the group and will assign the role when the group exists . In this box, you must create the "ESX Admins" group in the Active Directory. The host Will periodically check the domain controller for the group and Will assign the role When the group exists.

Here are some of the New features and enhancements for ESXi 4.1 and the vCLI

Get ready - THERE WILL BE NO MORE FULL ESX!! (or so VMware promises…)

Boot From SAN will be fully supported in ESXi 4.1. It was as only experimentally supported in ESXi 4.0. Boot from SAN will be supported for  FC, iSCSI, and FCoE – for the latter two, it will depend upon hardware qualification, so please check the HCL and Release Notes for vSphere 4.1.

Scripted Installation, the equivalent of Kickstart, will be supported on ESXi 4.1. The installer can boot over the network, and at that point you can also do an interactive installation, or else set it up to do a scripted installation. Both the installed image and the config file (called “ks.cfg”) can be obtained over the network using a variety of protocols. There is also an ability to specify preinstall, postinstall, and first-boot scripts. For example, the postinstall script can configure all the host settings, and the first boot script could join the host to vCenter. These three types of scripts run either in the context of the Tech Support Mode shell (which is a highly stripped down version of bash) or in Python.

In ESXi 4.0, Tech Support Mode usage was ambiguous. We stated that you should only use it with guidance from VMware Support, but VMware also issued several KBs telling customers how to use it. Getting into Tech Support Mode was also not very user-friendly.

In ESXi 4.1, Tech Support Mode (TSM) will be fully supported. You can enable and disable it either in the DCUI or in vCenter. TSM over SSH, aka Remote TSM, is also fully supported, and can enabled and disabled independently of local TSM.

The warning not to use TSM will be removed from the login screen However, anytime TSM is enabled (either local or remote), a warning banner will appear in vSphere Client for that host. This is meant to reinforce the recommendation that TSM only be used for fixing problems, not on a routine basis.

By default, after you enable TSM (both local and remote), they will automatically become disabled after 10 minutes. This time is configurable, and the timeout can also be disabled entirely. When TSM times out, running sessions are not terminated, allowing you to continue a debugging session. All commands issued in TSM are logged by hostd and sent to syslog, allowing for an incontrovertible audit trail.

Other new vCLI commands include network troubleshooting and new information exposed in resxtop. Finally, the ability to forcibly kill a VM has been added to vCLI, thus eliminating one of the most common reasons for wanting to use TSM.

There is now an ability to totally lock down a host. Lockdown mode in ESXi 4.1 forces all remote access to go through vCenter. The only local access is for root to access the DCUI – this could be used, for example, to turn off lockdown mode in case vCenter is down. However, there is an option to disable DCUI in vCenter. In this case, with Lockdown mode turned on, there is no possible way to manage the host directly – everything must be done through vCenter. If vCenter is down, the only recourse in this case is to reimage the box.

Of course, Lockdown Mode can be selectively disable for a host if there is a need to troubleshoot or fix it via TSM, and then enabled again.

http://www.vmware.com/products/vsphere/esxi-upgrade/

Forgive the corny humor…

The free ESXi Hypervisor is no more (well at least not by that name).

VMware have re-branded it as VMware vSphere Hypervisor (ESXi)

VMware vSphere Hypervisor FAQs

What is the difference between VMware ESXi and VMware vSphere Hypervisor?

 

VMware vSphere Hypervisor is the new name for what was formerly known as VMware ESXi Single Server or free ESXi (often abbreviated to simply “VMware ESXi”). VMware vSphere Hypervisor is the free edition of the vSphere production line. It is licensed to only unlock the hypervisor functionality of vSphere, but it can be seamlessly upgraded to more advanced offerings of VMware vSphere. VMware vSphere is available in multiple editions including several options specifically designed for small businesses.

How is the free VMware vSphere Hypervisor different than paid editions of VMware vSphere? How can I upgrade?

 

VMware vSphere Hypervisor is available at no cost in order to help companies of all sizes experience the basic benefits of virtualization. Granting free access to vSphere’s basic hypervisor functionality enables IT professionals to become familiar with the technology and prove its value in their own companies.

VMware vSphere Hypervisor can be seamlessly upgraded to more advanced editions of vSphere. Simply upgrade the free license to the desired upgraded vSphere license to take advantage of advanced vSphere functionally including centralized management, live migration of virtual machines, automatic load balancing, business continuity, power management, and back up and restore capabilities for virtual machines. VMware vSphere is available in multiple editions including two kits specifically designed for small businesses. A reason for moving to a paid kit or edition is that you could take advantage of the vSphere management server, called VMware vCenter Server, to enable centralized management.

What tools can I use to manage my free VMware vSphere Hypervisor license?

VMware recommends using the free VMware vSphere Client to manage VMware vSphere Hypervisor. You can use the vSphere Client to log into each vSphere Hypervisor host individually to manage it via the Graphical UI. You may also query the VMware vSphere Hypervisor host with the vSphere Command-Line Interface (vCLI). Note that the free VMware vSphere Hypervisor does not allow any configuration changes through the vCLI. You can also upgrade to more advanced editions of VMware vSphere to centrally manage your hosts with VMware vCenter Server.

Can I get support for VMware vSphere Hypervisor?

There are several free and paid support options for customers who use VMware vSphere Hypervisor. Please visit support for more details.

Can I run virtual machines created by Microsoft Virtual Server, Microsoft Virtual PC, or VMware Server on VMware vSphere Hypervisor?

Yes. You can use the free VMware vCenter Converter to import virtual machines that were created using VMware Server, Microsoft Virtual Server, or Microsoft Virtual PC version 7 or higher. VMware vCenter Converter also supports conversions from sources such as physical machines and certain 3rd party disk image formats. View the VMware vCenter Converter FAQs for further details.

What is the difference between VMware vSphere Hypervisor and VMware Server?

Both VMware vSphere Hypervisor and VMware Server are available for free. However, VMware vSphere Hypervisor is the recommended free solution for customers looking to get started with VMware virtualization. vSphere Hypervisor is an enterprise-class virtualization solution that offers the bare-metal architecture for near-native performance, features like memory overcommit to increase consolidation ratios and a cluster file system for managing virtual machine files on shared storage. VMware Server, on the other hand, installs as an application on Windows or Linux, relying on the operating system for resource management. This limits the performance and scalability. Virtual machines created using VMware Server can run on VMware vSphere Hypervisor, in some cases they must first be converted using the free VMware Converter.

Can I buy VMware vSphere Hypervisor preinstalled on servers?

VMware vSphere Hypervisor is the industry’s first hypervisor to be embedded in server hardware. Several VMware OEM partners and various system builders have already ship server units with the embedded vSphere Hypervisor .View the hardware compatibility list for a full list of the server models that have VMware vSphere Hypervisor preinstalled.

How do I use VMware vCenter Server to manage my VMware vSphere Hypervisor hosts?

VMware vCenter Server provides centralized management for VMware vSphere Hypervisor hosts and their virtual machines. To manage a VMware vSphere Hypervisor host with vCenter Server, you must have a vCenter Server Agent license, which is included in all paid editions of VMware vSphere.

What are the Hardware requirements for VMware vSphere Hypervisor?

The hardware requirements for the VMware vSphere Hypervisor can be found in our hardware compatibility list and setup guide.

What Operating Systems can I run on VMware vSphere Hypervisor?

VMware offers the broadest operating system support as compared to any other virtualization vendor. Visit the guest operating system compatibility guide for a full list of supported guest operating systems.

As Always, Test Before you deploy!!!

VMware Data Recovery 1.2 Available.

Release Notes - Download Link - Admin Guide

Here are some highlights of the new release:

• a file level restore client for Linux virtual machines
• ability to run up to 10 VDR appliances per vCenter Server instance
• ability to fast switch between the deployed appliances via the vSphere Client plug-in
• Miscellaneous vSphere Client Plug-In user interface enhancements including:
• The means to name backup jobs during their creation.
• Additional information about the current status of destination disks including the disk's health and the degree of space savings provided by the de-duplication store's optimizations.
• Information about the datastore from which virtual disks are backed up.

VMware vCenter Server 4.0 Update 2

Release Notes - Download Link

Here Are some Highlights of the new release

Guest Operating System Customization Improvements: vCenter Server now supports customization of the following guest operating systems:

• Windows XP Professional SP2 (x64) serviced by Windows Server 2003 SP2
• SLES 11 (x32 and x64)
• SLES 10 SP3 (x32 and x64)
• RHEL 5.5 Server Platform (x32 and x64)
• RHEL 5.4 Server Platform (x32 and x64)
• RHEL 4.8 Server Platform (x32 and 64)
• Debian 5.0 (x32 and x64)
• Debian 5.0 R1 (x32 and x64)
• Debian 5.0 R2 (x32 and x64)
• Resolved Issues
:In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.
• CIM and API
• Guest Operating Systems
• Licensing
• Miscellaneous
• Networking
• Security
• Server Configuration
• Storage
• Upgrade and Installation
• vCenter Server, vSphere Client, and vSphere Web Access
• Virtual Machine Management
• vMotion and Storage vMotion
• VMware High Availability and Fault Tolerance

VMware ESX 4.0 Update 2

Release Notes  -  Download Link

Here Are some Highlights of the new release

• Enablement of Fault Tolerance Functionality for Intel Xeon 56xx Series processors— vSphere 4.0 Update 1 supports the Intel Xeon 56xx Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel Xeon 56xx Series processors.
• Enablement of Fault Tolerance Functionality for Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors— vSphere 4.0 Update 1 supports the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors.
• Enablement of IOMMU Functionality for AMD Opteron 61xx and 41xx Series processors— vSphere 4.0 Update 1 supports the AMD Opteron 61xx and 41xx Series processors without input/output memory management unit (IOMMU). vSphere 4.0 Update 2 enables IOMMU functionality for the AMD Opteron 61xx and 41xx Series processors.
• Enhancement of the esxtop/resxtop utility— vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s, MBwrtn/s, cmds/s, GAVG/s(guest latency).
• Additional Guest Operating System Support— ESX/ESXi 4.0 Update 2 adds support for Ubuntu 10.04. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.
• Resolved Issues – In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.
• CIM and API
• Guest Operating System
• Internationalization
• Miscellaneous
• Networking
• Server Configuration
• Storage
• Supported Hardware
• Upgrade and Installation
• vCenter Server, vSphere Client, and vSphere Web Access
• Virtual Machine Management
• vMotion and Storage vMotion
• VMware High Availability and Fault Tolerance
• VMware Tools

So today we will deal with how to get the scripts into the an ESXi installation. On Part 3 we dealt with what the scripts were and how to to use them

So how do we get the script to run on startup?

The two things that need to be done are:

1. Add the script to /sbin/client.py
   
   

   # TCP client example
   import time
   import socket

   time.sleep(20)
   s = socket.socket()
   s.connect(("192.168.113.1",3333))
   s.send("14332354169934n2nduN")
   s.close()

2. Add a Startup script to /etc/rc.local.d/S99unattend
   
   

   #!/bin/ash

   export PYTHONHOME=/
   export PYTHONPATH=/lib/python2.5-visor:/lib/python2.5-visor/lib-dynload:/lib/pyt
   export PATH
   python /sbin/client.py

   
   The reason for all the exports are since the script is not really running under any specific user it will not load the path and the Python variables, hence the explicit declaration.

So in order for us to add this to an ESXi ISO we need to do the following:

1. Add /etc/rc.local.d/S99unattend to the oem.tgz file
2. Add /sbin/client.py to the oem.tgz file

Now why the oem.tgz. The oem.tgz file is a file that will be parsed for installation which allows for OEM's to add bits and pieces into the ESXi install if needed.

In a default ESXi ISO - these are the contents of the image:

What we will need to do is a bit of manipulation to add some files to the oem.tgz and also into the image.tgz. Why both files you may ask - in order to make the changes to the installation persistent they have also be updated into the install.tgz file.

The most comprehensive resource I have found on customizing the oem.tgz file is on
Dave Mischenko's site.

There is a project on http://code.google.com/p/mkesxiaio/ where the process is automated - I cannot say that I have tried this personally - but it is on my list of to-do things.

We are going to this manually to explain the process a bit more so you can understand it a bit better and change it to your needs if you would like

Tools for the job that are needed:

• winscp or pscp (if you are using a windows machine)
• Linux OS
• tar
• bunzip2
• bzip2
• mkisofs

Copy the iso image from VMware-VMvisor-Installer-4.0.0.Update01-208167.x86_64.iso to your Linux machine - you can use WinSCP or pscp.

pscp VMware-VMvisor-Installer-4.0.0.Update01-208167.x86_64.iso root@192.168.30.10:/myfolder

Create directories for the process

mkdir iso iso-mount oem image dd-image

Mount the CD

mount -o loop -t iso9660 VMware-VMvisor-Installer-4.0.0.Update01-208167.x86_64.iso iso-mount

Since this is read only copy files to iso directory

cp -r iso-mount/* iso/

Unmount and remove the folder

umount iso-mount/

rm -rf iso-mount/

Next we create the oem.tgz file

cd oem/

mkdir -p sbin etc/rc.local.d/

And now we create the script files.

The client

cat >> sbin/client.py <<EOF
# TCP client example
import time
import socket

time.sleep(20)
s = socket.socket()
s.connect(("192.168.113.1",3333))
s.send("14332354169934n2nduN")
s.close()
EOF

And the Startup Script

cat >> etc/rc.local.d/S99unattend <<EOF
#!/bin/ash

export PYTHONHOME=/
export PYTHONPATH=/lib/python2.5-visor:/lib/python2.5-visor/lib-dynload:/lib/python2.5-visor/site-packages
export PATH
python /sbin/client.py
EOF

Next we add the execute permissions

chmod -R 755 etc/ sbin/

Tar the file back up

tar czvf ../oem.tgz etc/ sbin/

The oem.tgz needs to be copied to two different locations

Copy to the first location

cd ..

cp oem.tgz iso/

Extract the installer image from the ISO

tar zxvf iso/image.tgz -C image/

We now extract the disk file

cd image/usr/lib/vmware/installer/

bunzip2 VMware-VMvisor-big-208167-x86_64.dd.bz2

Mount the image

mount -o loop,offset=$((512*8224)) VMware-VMvisor-big-208167-x86_64.dd ../../../../../dd-image/

2^nd location – copy the oem.tgz file into the dd-image

cp ../../../../../oem.tgz ../../../../../dd-image/

Unmount the image

umount ../../../../../dd-image/

Compress the file

bzip2 VMware-VMvisor-big-208167-x86_64.dd

Go back to the install directory

cd ../../../../

Re-create the install.tgz file

tar zvcf ../iso/image.tgz usr/

cd ../iso

Create ISO

mkisofs -o ../My_VMware-VMvisor-Installer-4.0.0.Update01-208167.x86_64.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table .

cd ..

if you would there after you can remove everything

rm -rf dd-image/ image/ iso/ oem*

And as you can there is my newly created ESXi iso with my customizations inside

I have created a file with all the commands that you can copy and paste into a shell session for your convenience.

The whole process took less than 8 minutes.

Next up will be how deploy this to an through PXE to a server.

Today we will deal with the client and server scripts, and before we start I would like to get the definitions straight.

Client Script: The script that is executed on the ESXi machine (Python)

Server Script:The script running on a Windows host that will configure the ESXi machine after deployment (Powershell)

So let's start. Here is the client script - it was adapted from here

# TCP client example
import socket
s = socket.socket()
s.connect(("192.168.113.1",3333))
s.send("myuniquestring")
s.close()

Simple isn't it? - Well for me to understand this took a while so I will try and explain in as much detail as possible.

Line 2. Import the socket module - which will allow us to to create the communication socket

Line 3. Create the variable s as a socket

Line 4. Connect to an "IP","port" - in my case 192.168.113.1 and port 3333 - You can define this to the IP and port of your choice

Line 5. Send a string of text. This again can be anything you would like - but I would define it as something unique so not to have any false positives.

Line 6. Close the connection - and close the script.

And in plain text - the machine will open a communication socket on port 3333 to 192.168.113.1, send myuniquestring and exit.

Now on to the Server script - adapted from here

###############################################################################################
##	TCP port Listener + Connect to ESXi
## 	Author: 	Maish Saidel-Keesing                        
##  	       	http://technodrone.blogspot.com				
##	Date:		April 15, 2010								
##	Version: 	1.0
##	Synopsis:	This script will configure a TCP listener that will recive a string
##		It will then connect to a ESXi machine ready to configure the instance
###############################################################################################

#Define parameters with setting default port
function Trace-Port {
	param ([int]$port=3333, [string]$IPAdress="192.168.113.1", [switch]$Echo=$false)
	
		#create a new .net listener object
		$listener = new-object System.Net.Sockets.TcpListener([System.Net.IPAddress]::Parse($IPAdress), $port)
		$listener.start()
		[byte[]]$bytes = 0..255|%{0}
		write-debug "Waiting for a connection on port $port..."
		$client = $listener.AcceptTcpClient()
		$script:remoteIP = $client.Client.RemoteEndPoint
		$stream = $client.GetStream()
		while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0)
		{
			$bytes[0..($i-1)]|%{$_}
			if ($Echo){$stream.Write($bytes,0,$i)}
		}
		$client.Close()
		$listener.Stop()
		write-debug "Connection closed."
} #end Trace-Port Function

####entry point to script

#set Parameters
$result = $null
$script:string = "myuniquestring"

trace-port | foreach {
	$script:output = ([char]$_)
	$script:result += $output
}

if ($result -eq $string) {
	Connect-VIServer -Server $remoteIP.Address.IPAddressToString -User root -Password ""
}

Line 12. Two Parameters are passed by default to the script, IP and Port

Line 15. Create the listener object using the two parameters above

Line 16. Start the listener

Line 19. Open the TCP Client connection

Line 20. Assign the incoming IP to the remoteIP variable. The variable is in the Script Scope - so that I can use it again outside the function.

Line 22-26. In essence the input is translated into characters until the connection is closed

Line 27-28. Close the connection and then close the listener.

Line 35-36. Clear the results variable and define my unique string variable

Line 38-40. Get each character that is sent to the listener, and put it in the result string

Line 43.44. If the string that is sent matches the string I defined - then connect to the ESXi server with the remoteIP variable. The username is always root and password is always empty. This is the default of an ESXi installation.

And in Plain text - wait for a connection on port 3333. Once received  - check the string that is sent through this connection matches the string that is have predefined. If so that means it is a connection from an ESXi machine and that a connection should be opened to the ESXi server.

Now of course this is just a proof of concept for the script - but you should understand that once you can connect to the ESXi machine with root privileges you can configure what ever you would like.

Now of course to run the Server script, all you need is Powershell and the PowerCLI Cmdlets installed,

Next up is how to get the script into the ESXi installation process.

Today we will be dealing with some details of the parts involved. In my previous post - I explained the rationale behind the whole process.

So let us get into the schematics.

An ESX server can be installed with a kickstart script. There are multiple posts all over the web on how to configure this and customize the process. In a nutshell - most of the additional customization is performed in the %post section

%post (optional)

Executes the specified script after package installation has been completed. If you specify multiple %post sections, they are executed in the order they appear in the installation script.

As I said in my previous post - one of the reasons for doing this was because there is no kickstart for ESXi, it is whole different process. Two of the best posts I have read are on this here and here

The way it works is that ESXi boot into a full ESXi environment from the ISO image. It then kicks off an install process to ask you for input:

• Which disk..
• Eula
• etc. etc.
• Install
• Reboot
• Hey presto - you have an ESXi

It then formats the disk with VMFS and configures the boot partition to start off the ESX Kernel on the next boot. Andrew gives a much better explanation than I do so read the posts above.

Ok then what? you cannot perform any customization.

So the options (as I saw them) were:

• Dig into the Python Libraries in the installation source and customize the installation
  
  That was not what I wanted because:
• The learning curve to learn a new language - not something I am up to at the moment.
• This would be good for the one installation but what about the subsequent installations. And if I want to make a change to the process, this did not seem viable to me.
• Take the customization process out of the installation and like the kickstart do it post installation.

Ok so how?

The solution I came up with was based on the solution provided by Lance Berc.

What Lance did was to provide a parameter to the PXE boot parameters including a variable called PBHOST which is an IP address

#
# This code assumes that an argument has been passed via PXE which points
# pbconnect to the configuration service.  The format is PBHOST=<host:port>
# and it goes just after the vmkernel.gz argument in the configuration line,
# for example:
# append vmkernel.gz PBHOST=192.168.2.253:3333--- binmod.tgz --- environ.tgz --- cim.tgz --- oem.tgz --- lance-boot.tgz
# The vsish line is for compatibility with VI4.  It should be conditional based on uname -a
awk -f /sbin/pbconnect.awk /var/log/messages > /tmp/pb.tmp
vsish -e get /system/bootCmdLine | awk -f /sbin/pbconnect.awk >> /tmp/pb.tmp
#cat /tmp/pb.tmp
source /tmp/pb.tmp
if [ x$PBHOST != "x" ] ; then (pbconnect $PBHOST &) ; fi

What the process would do is look in the boot log. If it found the PBHOST in then it would fire-off a connection script. called pbconnect which is part of the lance-boot.tgz that was passed in the PXE boot.

Ok first my issues with the process:

• Not all installations are performed with PXE.
• The pbconnect is (i think) a compiled program  - and I wanted something that could be customized and changed if needed.

On the other side there was a midwife script. This script consisted of Perl script that would listen for connections and once connected would fire off the customizations process (which is was a Powershell process)

I also had a few problems with this:

• Perl is not my cup or tea - I will leave this to William Lam
• In order for this to run I would have to have both Powershell and Perl on the machine.
• Why not do it all in one language? - my preference - Powershell.

So to recap slightly - the process was to run a script after installation, connect to a listener on another host and once the connection is made the "midwife would configure the machine.

This is I guess the was that VMware are moving forward seeing that they put this into Stateless VMware ESXi Server Version 3.5 Update 4 Using PXE Booting

This is already built into the VMkernel in starting from ESXi 3.5 U4 and in an ESX4i as you can see from the log of the ESXi host. This in the /var/log/messages

Apr 23 05:33:16 vmkernel: sysboot: Getting 'PBHOST' parameter from kernel boot line

Next post up - The Client and Server scripts.

I posted a small preview about a new ESXi Deployment Solution.

First question I would like to answer is why?

1. Why is a Deployment solution needed for ESXi?
2. Why is it any different to Deploying the full ESX version?

So the answers were:

1. VMware has announced multiple times that ESXi will be the platform of choice for the next version of ESX. They are moving away from the Service Console for a multitude of reasons.
   
   The same way that you as a Virtualization Administrator would like to prepare a standard installation configuration for all your ESX Hosts, I am sure that you would like to deploy a standard ESXi across your environment.
2. ESX you can deploy with a kickstart script. This is fully supported by VMware. At present there are two Virtual Appliances that you can use to deploy ESX, namely the UDA and the EDA. Personally I prefer using the UDA, just came more naturally to me. With the customization of kickstart script you can practically do what you would like - anything that can be run from the command line.
   
   Back to ESXi. At present there is no way to mass deploy - at least not any officially supported by VMware method. There are one or two mentions of how to do this. I do suppose (or so I am told) that this functionality will be available before we are all moved off of the Service Console.

Next Question is - what?

1. What can you do with this deployment solution?
2. What components will I need for this solution?

And the Answers:

1. Anything you can do with the API, you can configure through this solution. Including adding the host to a cluster, patching, the options are almost endless
2. a. PowerCLI
   b. PUTTY (or ssh client of your choice)
   c. One of the above mentioned deployment appliances (NOT compulsory) or a CD burner to create an
       ISO

And now for the open topic questions:

1. Can this be used as a replacement for Host Profiles (which is only available in Enterprise Plus)?
2. Will this be customizable - Can I make changes to suit my environment?
3. Does this contain any proprietary code or compiled executables?
4. How is this different to the mentions above of how to deploy ESXi?

The Answers:

1. Host Profiles deals (at least the way I see it) with two different issues.
   a. Initial Configuration
   b. Compliance to a Baseline
   This solution will deal with the initial configuration only - it will not track to the compliance to a baseline thereafter.
2. Yes and yes. The changes you will make will be limited only by what the vSphere API can do, and what changes you would like to put into the configuration script.
3. Nope. All Powershell and Python - taken from example freely available on the internet.
4. The idea is basically the same. There is the same kind of client/server framework. The ESXi host is deployed and when completed it notifies (client) a Powershell script (server) of its existence. The script then performs the configuration steps that you define on the new host. I was not satisfied with the results I was getting from the ideas that were posted above. There are some flaws in the process (at least from my point of view) and the flexibility of being able to make changes was minimal. I find that this new approach simplifies things for me and allows for greater flexibility.

So when will we see how this works?

I will be posting in the next upcoming posts, the process of setting up this system.

Comments and questions are always welcome.

Well after cursing more than once at Python on Twitter over the past week or so - I finally got managed to overcome

This is a sneak preview of my ESXi Deployment Solution

How exactly it works - will come in the next few days with a detailed explanation.

I can tell you it is made up of several components including:

• PowerCLI
• Python
• Deployment appliance

Here is a video of the process below.

As I posted a few weeks ago - I entered the ESXi Script-0-Mania Contest.Unfortunately, my entry was not chosen as one of the top entries, but hey - I don't do this for the money - I enjoy what I do - I feel that the contribution back to the virtualization community is the least I can do - seeing the amount of info and help that I receive from you all.

So - Deploy-ESXi.ps1 v1.0 - My entry. As you can deduct from the script name this script does what it says.

The need for the script? I find that I am deploying more and more systems with ESXi - be it the free version - or a fully-licensed system. Now of course to install ESXi is really, really simple!
I mean F11 -> Enter -> Enter … and Bob's your uncle - or you have an ESXi server deployed - that's it. But then you have the mundane tasks of configuring the installation according to your requirements. Removing Default port groups, changing the Management IP, set NTP settings. I guess you understand what I am talking about. Now of course all of this can be scripted with a Kickstart script - but guess what ?? No Kickstart script for ESXi!! So either you have to do this manually - or if you some of the Enterprise customers - you can utilize Host Profiles to do all of this for you.

Or you can use this script as a base for your environment.

You might say that this will not work with the free version of ESXi because the API is read-only in this version. Well that is true - but by default the new installation is deployed with a fully functional evaluation license which makes the API read-write and allows you to make the changes you need

The script is commented within.

############################################################################
##	ESXi Deployment script                                     			
## 	Author: 	Maish Saidel-Keesing                        				
##  	       	http://technodrone.blogspot.com			
##	Date:	March 15, 2010				
##	Synopsis:	This script will configure an ESXi server			
##			that has been installed with several basic settings			
############################################################################
#
#When an ESXi machine is installed there are basic default settings that we will define
#
#1. Connect to host with default credentials (root,<empty>)
#2. Remove Default VM Network Portgoup
#3. Add VM Portgroup named Virtual Machines and raise the number of port on the virtual Switch
#4. Set NTP Servers
#5. Adding a new root user 
#6. Change Management IP and DNS
#7. Backup configuration to a network share
#8. Change Default password
#9. Reboot the Host after all the changes
#10. Send email to admin of installation particulars

#Set Default variables
$defaultuser = "root"
$defaultpwd = ""
$esxi = Read-Host Please enter the IP of the ESXi server


#connect to ESXi
Write-Host -ForegroundColor Green Connecting to ESXi server
Connect-VIServer $esxi -User $defaultuser -Password $defaultpwd


##2. Remove Default VM Network Portgoup
Write-Host -ForegroundColor Green Remove Default VM Network Portgoup
Get-VirtualPortGroup -Name "VM Network" | Remove-VirtualPortGroup -Confirm:$false

##3. Add VM Portgroup named Virtual Machines and raise the number of port on the virtual Switch
Write-Host -ForegroundColor Green Changing Portgroup and Default vSwitch settings
Get-VirtualSwitch -name vSwitch0 | New-VirtualPortGroup -Name "Virtual Machines" -Confirm:$false
Get-VirtualSwitch -Name vSwitch0 | Set-VirtualSwitch -NumPorts 120 -Confirm:$false

##4. Set NTP Servers
Write-Host -ForegroundColor Green NTP Settings
Add-VmHostNtpServer -NtpServer "pool.ntp.org" -Confirm:$false

##5. Adding a new root user 
Write-Host -ForegroundColor Green Adding new root user
New-VMHostAccount -ID User1 -Password "Qwer$#@1" -UserAccount:$true
Set-VMHostAccount -GroupAccount root -AssignUsers User1
Set-VMHostAccount -GroupAccount localadmin -AssignUsers User1
Set-VMHostAccount -UserAccount User1 -UnassignGroups users

##6. Change Management IP and DNS
Write-Host -ForegroundColor Green Changing Mgmt IP and settings
$mgmtip = Read-Host Please Enter the Management IP address
$mgmsm = Read-Host Please Enter the Management Subnet Mask
$hostname = Read-Host Please Enter the ESXi Hostname
$domainname = Read-Host Please Enter the ESXi Domain Name
$dns1 = Read-Host Please Enter the DNS Server IP

Get-VMHostNetworkAdapter | Where-Object {$_.PortGroupName -eq "Management Network" } | `
	Set-VMHostNetworkAdapter -IP $mgmtip -SubnetMask $mgmsm 
Get-VMHostNetwork | Set-VMHostNetwork -HostName $hostname -DomainName $domainname -DnsFromDhcp:$false -DnsAddress $dns1

##7. Backup configuration to a network share
Write-Host -ForegroundColor Green Backing up configuration
$share = Read-Host Please enter the network share you would like to save the configuration to
Set-VMHostFirmware -BackupConfiguration -DestinationPath $share

##8. Change Default password
Write-Host -ForegroundColor Green Changing Default Password
$newpasswd = "Qwer$#@!"
Set-VMHostAccount root -Password $newpasswd

##9. Reboot the Host after all the changes
Write-Host -ForegroundColor Green Rebooting Host

Set-VMHost -state "Maintenance"
Restart-VMHost -Force:$true -Confirm:$false
sleep 60

##10. Send email to admin of installation particulars

#Wait for the host to come up
Connect-VIServer -Server $mgmtip -User root -Password $newpasswd
	while ($? -ne $true ) {
		sleep 30; write-host -ForegroundColor Red Still Waiting for Host to come back up; Connect-VIServer -Server $mgmtip -User root -Password $newpasswd
	}

Write-Host -ForegroundColor Green Host is available
$body = @"
Management IP address: $mgmtip
Management Subnet Mask: $mgmsm
ESXi Hostname: $hostname 
ESXi Domain Name: $domainname 
DNS Server IP: $dns1 
"@

Send-mailmessage -From "esxideploy@maishsk.local" -To "maish@maishsk.local" -Subject "New ESXi Server installed" -bodyasHTML $body -SmtpServer "smtp.maishsk.local"

Annotations:

23-26. Setting the default variables. All ESXi servers are set with a blank password on first configuration.

47-52. Here I created a another Admin User on the ESXi host - an additional Admin account for troubleshooting - if needed.

66=69. After configuration is completed - configuration is backed up to share - in case it is needed for restore.

71-74. We of course do not want to leave the default blank password

86-89. Check that the server has come up

92-100. Send Email to Administrator with new host details.

Things that will be added in future versions:

• Logging to file / database
• Checks after connections - and timeouts
• Other improvements

I have plans for this script - and the development further so stay tuned for this spot

You can download the script below

A demo of how the script works below

I was one of a few blogger that were invited to participate yesterday in a Bloggers briefing -
given by Doug Hazelman - presenting Veeam's new product Surebackup.

Well this is not actually a new product as such - but a family of the current technologies that Veeam use with the addition of one significant new feature that will be introduced in Q3 of 2010 in Backup and Replication v5.

Some of the points that were shown at the briefing - which I am sure will be public as well after the announcement.

One of the biggest issues Administrators have with verifying the validity of Backups of an OS is that when doing this you cannot only rely on the restore only of one restored system.

Let me give you an example:

Verify an Exchange Backup. For this you will need Exchange, DNS, Active directory , which means we are not talking only about one system, but multiple systems. The same would go for almost any Web application restore as well.

Now in the case of the Exchange backup, the restore will entail not only multiple Operating Systems, but also having to isolate these machines from the production Network.

So as you can see - we all have a problem with attesting to the reliability of the backups that we take - will they actually work when push come to shove? It is not a definite answer - one way or the other.

So how will SureBackup help us out? With the new technology - you will be able to to verify the backups of your VM's . How will this be done? The VM's can be brought up in a fenced environment (isolated) and they can be "packaged" as a vApp to come up as a group. But even more so - you will be able to run these VM's from the compressed backup files - without even having to inflate them. One thing that all participants were amazed about was the information below

And a slide to give a bit more info about the process and something to think about the future

  Some other points to note:

• The restore can be done on existing ESX hosts - no extra licenses are needed.
• The restore and verification can be done directly to your DR site - because it will be on an NFS store that can be mounted (of course this will be automated to say you loads of time)
• This will not be a replacement for SRM

I for one will be looking forward to the Beta for the Product when it is released - this will be an interesting one!

Thank you again Doug for the opportunity to

Last week I posted the link to the Beta release. Today Veeam announces the release of version 3.0.2 that now supports Windows 7 and Windows 2008 R2.

Release Notes

New Features

The following is a list of new features introduced in the Veeam FastSCP 3.0.2:

• Added support for Microsoft Windows 7 and Microsoft Windows Server 2008 R2
• VMware vSphere 4 is now “officially” supported.

The following is a list of new features introduced in the Veeam FastSCP 3.0.1:

• Added support for ESX 3.5 Update 4.

The following is a list of new features introduced in the Veeam FastSCP 3.0:

• Full ESXi support.
• Improved file copy scheduling options
• Improved user interface

Resolved Issues

The following is a list of issues resolved in the Veeam FastSCP 3.0.2:

FastSCP doesn't process flat.vmdk files on ESX(i) 4 when using agentless mode

The following is a list of issues resolved in the Veeam FastSCP 3.0.1:

• Inactive datastore error when trying to copy files to/from online NFS datastore connected to an ESXi host.
• If the daily scheduled copy job’s schedule is set to skip some days, the job always start at 12am on the next day it is allowed to run.
• Unknown api version error displayed when processing vCenter containing older versions of ESX servers (prior to ESX 3.0).
• File deletion errors are not displayed correctly

Known Issues

The following is a list of issues known to exist at the time of the Veeam FastSCP 3.0.2 release:

General 

• Creating new folder, and copying files within the same datastore fails with COM error () is not
  when FastSCP is installed on the 64bit OS and agentless data transfer mode (ESXi) is used. Service console agent based data transfer mode ESX and Linux is not affected.
• Scheduled file copy job statuses do not refresh automatically. Click the Refresh button to update the status for all jobs when required.
• Under certain circumstances, making changes in FastSCP user interface while a file copy job is running may result session information and statistics loss.
• Local administrator rights are required to setup and run FastSCP.

Duncan posted this one this evening.

So to add to his post there is a way to "hide" the web service at least front page

in ESXi the configuration file that is responsible for all this is /etc/vmware/hostd/proxy.xml

<ConfigRoot>
  <EndpointList>
    <_length>10</_length>
    <_type>vim.ProxyService.EndpointSpec[]</_type>
    <e id="0">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <accessMode>httpsWithRedirect</accessMode>
      <port>8309</port>
      <serverNamespace>/</serverNamespace>
    </e>
    <e id="1">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <accessMode>httpsWithRedirect</accessMode>
      <port>8307</port>
      <serverNamespace>/sdk</serverNamespace>
    </e>
    <e id="2">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <accessMode>httpsWithRedirect</accessMode>
      <port>8308</port>
      <serverNamespace>/ui</serverNamespace>
    </e>
    <e id="3">
      <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
      <accessMode>httpsOnly</accessMode>
      <pipeName>/var/run/vmware/proxy-vpxa</pipeName>
      <serverNamespace>/vpxa</serverNamespace>
    </e>
    <e id="4">
      <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
      <accessMode>httpsWithRedirect</accessMode>
      <pipeName>/var/run/vmware/proxy-mob</pipeName>
      <serverNamespace>/mob</serverNamespace>
    </e>
    <e id="5">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <!-- Use this mode for "secure" deployment -->
      <accessMode>httpsWithRedirect</accessMode>
      <!-- Use this mode for "insecure" deployment -->
      <!-- <accessMode>httpAndHttps</accessMode> -->
      <port>8889</port>
      <serverNamespace>/wsman</serverNamespace>
    </e>
    <!-- Needed because old versions of the VI client access
         the clients.xml file over Http for upgrade -->
    <e id="6">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <accessMode>httpAndHttps</accessMode>
      <port>8309</port>
      <serverNamespace>/client/clients.xml</serverNamespace>
    </e>
     <e id="7">
      <_type>vim.ProxyService.NamedPipeTunnelSpec</_type>
      <serverNamespace>/sdkTunnel</serverNamespace>
      <accessMode>httpOnly</accessMode>
      <pipeName>/var/run/vmware/proxy-sdk-tunnel</pipeName>
     </e>
    <e id="8">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <accessMode>httpAndHttps</accessMode>
      <port>12001</port>
      <serverNamespace>/ha-nfc</serverNamespace>
    </e>
    <e id="9">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <accessMode>httpAndHttps</accessMode>
      <port>12000</port>
      <serverNamespace>/nfc</serverNamespace>
    </e>
  </EndpointList>
</ConfigRoot>

The part we are interested in is this

In order to mask the web page all that you need to do is change the port number in the config file and this will lead you to blank page

    <e id="0">
      <_type>vim.ProxyService.LocalServiceSpec</_type>
      <accessMode>httpsWithRedirect</accessMode>
      <port>8499</port>
      <serverNamespace>/</serverNamespace>
    </e>

<!--e id="4">
      <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
      <accessMode>httpsWithRedirect</accessMode>
      <pipeName>/var/run/vmware/proxy-mob</pipeName>
      <serverNamespace>/mob</serverNamespace>
    </e-->

The same way you could mask any of the other services you would like (mob etc..)

Restart the services on the Host with

/sbin/services.sh restart

Before

And after

Update: William Lam also posted a 3rd method that did not need going into the unsupported Dropbear console. Well worth a read!!