If you haven’t already used the vMA (vSphere Management Assistant) then I strongly encourage you to do so as it’s an essential tool in managing your ESX and ESXi hosts, and it really makes the transition from ESX to ESXi straight forward. Understanding and using the vMA is part of section 8.3 in the VCAP-DCA blueprint.

Commands Covered

• domainjoin-cli
• visudo
• vifptarget
• vicfg-nics
• vicfg-syslog
• vifp listservers
• vma-update
• vicfg-syslog
• vilogger
• vifptarget (vifpinit)
• resxtop

Configuring Active Directory Authentication

Log into vMA as vi-admin then:

# sudo domainjoin-cli join mydomain.local administrator
# sudo domainjoin-cli query
# sudo reboot

Adding an Active Directory Group to the Sudoers file

Log into vMA as vi-admin then:

# sudo visudo

Add a new line under the entry for root:

root    ALL=(ALL)       ALL
%MYDOMAIN\\Domain\ Admins ALL=(ALL) ALL

This translates to: MYDOMAIN\Domain Admins can run from ALL terminals, acting as ALL (any) users, and run ALL (any) command. The reason there are two backslashes before the domain name is because the first slash is an escape character, and says to allow the next character. A backslash is also required when spaces exist, in our case Domain Admins. Again, Domain\ Admins means that it should allow the space.

Save and exit the sudoers file (:wq)

Add vCenter server to vMA

Log into vMA as vi-admin then:

# sudo vifp addserver vcenter.mydomain.local --authpolicy adauth --username mydomain\\administrator

To set this as the default target:

# vifptarget -s vcenter.mydomain.local

Verify that your target has been set:

# vifptarget -d

It should display the hostname of your vCenter server.

Make sure you can run commands against one of your hosts in vCenter:

# vicfg-nics -l --vihost <FQDN of your ESX host>

Tip: Make sure you enter the fully qualified domain name otherwise it will not find the ESX host.

List servers that have been added

# vifp listservers

Removing a server from the vMA

Log into vMA as vi-admin then:

# sudo vifp removeserver vcenter.mydomain.local

Using vma-update (vima-update)

# sudo vma-update scan
# sudo vma-update update

Configuring the default user profile in Windows 7

When creating your base (parent) image you may want to configure the default user profile so when new users log into the desktop for the first time, it retains certain customisations such as the desktop background colour, shortcuts, etc.  Prior to Windows 7 you were able to copy a user profile to the default user profile, but Windows 7 does not permit this method. Instead, you must create an unattend.xml (unattended installation file) with Windows System Image Manager (WSIM) which is part of the Windows Automated Installation Kit.

You want to keep your base build as clean as possible, so I suggest installing the Windows AIK on to another machine so you can create your unattend.xml file.

Step 1: Download and Install the Windows Automated Installation Kit.

Step 2: Launch Windows System Image Manager (Start > All Programs > Microsoft Windows AIK)

Step 3: Select Windows Image (File > Select Windows Image), navigate to your Windows 7 Enterprise CD and select install.wim from the sources directory.

Step 4: In the Windows Image section (bottom left), navigate to Windows 7 ENTERPRISE > Components > x86_Microsoft-Windows-Shell-Setup_6.1.7600.16385_neutral, then right click and select ‘Add Setting to Pass 4 specialize’. If you are using an AMD processor then simply select the alternative for amd64.

Step 5: In the answer file section (top middle), you should now see x86_Microsoft-Windows-Shell-Setup_neutral listed under 4 specialize. Click on this, and in the properties pane (top right) you need to change CopyProfile to true. Save your newly created answer file as Untitled.xml on to the C: drive of your Windows 7 base image.

Step 6: On your Windows 7 build, make sure you are logged on as a local administrator then run the following: %systemroot%\system32\sysprep\sysprep.exe /oobe /reboot /generalize /unattend:c:\Unattend.xml. Sysprep will now run and copy the profile of the currently logged on user as the default, then it will reboot the machine.

Once Sysprep has rebooted your virtual machine, finish the setup wizard and any final tweaks you wish to make before shutting it down and making it active for your View desktop pool (you are doing this with VMware View right?).

If you are looking to deploy multiple ESX/ESXi servers then there are plenty of methods and tools out there, some more complex than others. There are vendor specific deployment products available such as HP Rapid Depuployment Pack (RDP) which uses Altiris, or alternatively there are free deployment tools such as ESX Deployment Appliance (EsleeDA) and Ultimate Deployment Appliance (UDA). UDA is my favorite tool for the job as it offers great flexibility such as the use of subtemplates (discussed later), and therefore this will be the basis of this article. It was created by Carl Thijssen and thanks to Mike Laverick of RTFM, it also supports ESX/ESXi deployments, and the latest build supports ESX/ESXi 4.1.

I aim to share the basics of getting the UDA configured for your environment and not delve into anything too complicated here. The best way of learning to perform some of the more complex deployments are to grasp the basics first then experiment with other functionality in your own environment for yourself. Mike Laverick has an excellent guide on deploying and configuring UDA 2.0 beta.

For the purposes of this guide a number of assumptions have been made. You will have already deployed vCenter and at least one ESX/ESXi host running with some storage. If you are going to be testing this in a home lab then bear in mind that we’ll need to configure DHCP options 66 and 67, see the end of this article for details. You can do this with an existing DHCP server or use UDA as a DHCP server. Most deployments will be using an existing DHCP server.

Let’s get started…

Step 1: Download & Deploy the Ultimate Deployment Appliance

1) Download UDA from: http://www.rtfm-ed.co.uk/vmware-content/ultimate-da/ then extract it to your hard disk.
2) Import the appliance using your vSphere client (File > Deploy OVF Template...)
3) Prior to powering on the appliance, add a second disk that we’ll use to store your ISO images. I’d recommend at least a 20GB disk, and use thin to conserve disk space.
4) Power on and proceed to the next step.

Step 2: Installation and Setup

1) Click OK at the welcome screen
2) Enter the hostname (I recommend that you also add the hostname into your DNS server)
3) Enter the IP address configuration
4) Select the services you require (as a minimum I would just leave TFTP, HTTP and SSH selected)
5) Enter the root password.
6) Select Yes to apply the changes.

Once it has finished you will then be able to access your UDA from a web browser. Log in with admin and the password you set during the setup.

Step 3: UDA Configuration

When you first log into the appliance you will be presented with a welcome page. The first thing to configure is the additional disk space we need to store our ISO images. If you haven’t added a second hard disk, then shutdown the UDA (System > Shutdown), then add the additional disk and power on.

UDA has two partitions; systemlv and localv. ISO images are stored on the localv partition, so we’ll extend that.

1) Go to System and click Diskspace.
2) Select localv and then click Extend.
3) Select the device and then click Apply.

It may take a little while depending on how large the new disk is, but once that is complete we’ll load the ISO image for ESXi 4.1 Update 1 on to the UDA.

1) Go to System and click Upload.
2) Click Choose File, select your ISO then click Upload.

It will store the ISO on the localv partition in /local.

Step 4: Add an OS & Deployment Template for ESXi 4.1

Now for the exciting bit. We’ll add our OS (ESXi) and template for deployment which will also create the basics of our Kickstart script which we’ll add to later. The OS section allows us to tie an ISO image to a Flava name, in this case we’ll call it ESXi41. I’d recommend using a better naming convention for your environment though.

1) Go to OS and click New.
2) Enter ESXi41 for the Flava Name.
3) From the dropdown, choose VMware ESXi 4.1 Installable and click Next.
4) Select the ESXi 4.1 ISO you uploaded and then click Finish.

Next, the template which contains our Kickstart script. The template also contains a subtemplate which allows us to define our own variables, such as IP address and hostnames for each ESXi host we are deploying. This is why I like using UDA so much, because it avoids having to create a separate Kickstart script for each ESXi host.

1) Go to Templates and click New.
2) Enter a Template Name. For example: esxi-build and give it a meaninful description.
3) From the Operating System dropdown choose VMware ESXi 4.1 Installable and click Next.
4) From the Flava dropdown choose your OS (Flava), ESXi41 and click Next then Finish.

The next stage is to perform the configuration of our Kickstart script and subtemplate. Go to Templates, select your template (esxi-build) and click Configure. You’ll see three tabs here; General, Subtemplates and Advanced. Click on Advanced. This is where our Kickstart script lives, and you’ll see it contains a basic configuration.

Here is a breakdown with explanations for each line:


# Accept the VMware EULA - The script will fail without this.
accepteula

# Set the root password using MD5 crypt
rootpw secret

# Auto partition the disk
autopart --firstdisk --overwritevmfs

# Location of the install media
install url http://[UDA_IPADDR]/[OS]/[FLAVOR]

# Configure IP address and hostname. --addvmportgroup=0 will disable creation of the VM Network portgroup
network --bootproto=static --ip=192.168.178.200 --gateway=192.168.178.1 --nameserver=192.168.178.1 --netmask=255.255.255.0 --hostname=esx41i --addvmportgroup=0

# Reboot the host when the installation is complete
reboot

The first thing we need to change is the root password which by default is set to secret and is in plain text. We can use a crypted MD5 password here using rootpw --iscrypted followed by the crypt.

1) Log into your UDA with PuTTY (SSH) and log in as root (same password you set during the initial setup).
2) Type grub-md5-crypt
3) Enter your password and it’ll generate an MD5 string for you.
4) Go back to the Advanced view in the web interface and change the rootpw line to (replacing the crypt with the one you generated):

rootpw --iscrypted $1$3vkd233f/wksSo$fhniM3fdcV6hr0

Now we need to change the network configuration to use the appropriate IP address, gateway, subnet mask and hostname. We could just replace the default IP address configuration here, but a better method is to use variables which we can set in subtemplates. Variables are set inside square brackets, such as [IPADDR], [FQDN] and so on. The variable names are up to you. Change the network configuration, replacing the IP address and hostname with variables as follows:

network --bootproto=static --ip=[IPADDR] --gateway=192.168.4.1 --nameserver=192.168.4.1 --netmask=255.255.255.0 --hostname=[FQDN] --addvmportgroup=0

Select Subtemplates and click on Edit. The first line we will create contains the word SUBTEMPLATE then the variable names that we want to use (separated by semi-colons). Subsequent lines contain the values for each host. See my example below:

SUBTEMPLATE;IPADDR;FQDN;VMKIPADDR
ESX01;192.168.4.11;esx01.home.lab;192.168.4.211
ESX02;192.168.4.12;esx02.home.lab;192.168.4.212
ESX03;192.168.4.13;esx03.home.lab;192.168.4.213
ESX04;192.168.4.14;esx04.home.lab;192.168.4.214

You’ll notice in my example I’ve added a VMkernel IP address that in the case of our ESXi deployment we will use for VMotion.

Click on the Advanced tab. After the network configuration line we need to add the following command which allows us to run our esxcfg commands on first boot:

%firstboot --unsupported --interpreter=busybox

Now add the following commands to the Kickstart script (Advanced), which will add a VMotion portgroup and IP address. You can leave the # comments in if you wish:

# Setup VMotion portgroup on vSwitch0
esxcfg-vswitch -A VMotion vSwitch0

# Setup VMotion IP address
esxcfg-vmknic -a VMotion -i [VMKIPADDR] -n 255.255.255.0

# Wait for previous command to finish before enabling VMotion
sleep 10

# Enable VMotion (ESX uses vmware-vim-cmd and ESXi is vim-cmd)
vim-cmd hostsvc/vmotion/vnic_set vmk1
vim-cmd hostsvc/net/refresh


Notice in the vim-cmd command above that it sets VMotion on vmk1. vmk0 will be the management IP address used in the network command at the top of our script. This is fairly straightforward to work out, but if anyone knows of a better method then feel free to comment!

Finally click on Save.

The Deployment

Now we have the UDA configured and ready to roll with our ESXi installation all we have to do now is PXE boot our hosts and providing you have configured DHCP options 66 & 67 (see the end of this article) you should be presented with the UDA menu (see first screenshot).

The rest is easy, just select the host from the menu (we set this in SUBTEMPLATE) and it will install and configure ESXi with no user intervention. Using a scripted installation can be very powerful and a lot more can be configured than I’ve included here. Even if you don’t have mass ESXi deployments, this is a good way of ensuring that your ESXi hosts maintain your standard build. If you have an Enterprise Plus license then you can also use Host Profiles.

Kickstart script:

accepteula
rootpw --iscrypted $1$3vkd233f/wksSo$fhniM3fdcV6hr0
autopart --firstdisk --overwritevmfs
install url http://[UDA_IPADDR]/[OS]/[FLAVOR]
network --bootproto=static --ip=[IPADDR] --gateway=192.168.4.1 --nameserver=192.168.4.30 --netmask=255.255.255.0 --hostname=[FQDN] --addvmportgroup=0
reboot

## THE FOLLOWING IS OUR FIRSTBOOT CONFIGURATION ##

# Configure additional commands at first boot.
%firstboot --unsupported --interpreter=busybox

# Setup VMotion portgroup on vSwitch0
esxcfg-vswitch -A VMotion vSwitch0

# Setup VMotion IP address
esxcfg-vmknic -a VMotion -i [VMKIPADDR] -n 255.255.255.0

# Wait for previous command to finish before enabling VMotion
sleep 10

# Enable VMotion (ESX uses vmware-vim-cmd and ESXi is vim-cmd)
vim-cmd hostsvc/vmotion/vnic_set vmk1
vim-cmd hostsvc/net/refresh

SUBTEMPLATE:

SUBTEMPLATE;IPADDR;FQDN;VMKIPADDR
ESX01;192.168.4.11;esx01.home.lab;192.168.4.211
ESX02;192.168.4.12;esx02.home.lab;192.168.4.212
ESX03;192.168.4.13;esx03.home.lab;192.168.4.213
ESX04;192.168.4.14;esx04.home.lab;192.168.4.214

Configuring DHCP Options

1) Set option 66 to the IP address of your UDA
2) Set option 67 to pxelinux.0

If you find that when typing text using the VMware virtual machine console on a low bandwidth connection,  it repeats characters (no matter how careful you are). Try setting the following configuration parameter:

keyboard.typematicMinDelay = 2000000

You’ll need to power off your VM first, then add this to the end of your configuration (.vmx) file. If you are using VMware ESX/ESXi then edit the settings of the virtual machine and go to Options then Advanced, General > Configuration Parameters.

VMware KB 196: http://kb.vmware.com/kb/196

The vSphere Management Assistant (vMA) runs a 64 bit operating system (RedHat Enterprise Linux) and features the VMware vCLI in addition to vSphere SDK for Perl, Java JRE, CIM vSphere profiles, VMware tools and an SNMP agent. The vMA virtual machine requires a single vCPU with 512MB memory and a 5GB virtual disk. If you are studying for the VCAP-DCA exam then you will need to know how to install and use the vMA to manage a vSphere environment. The best way to learn how to use the vMA is to setup your own home lab. I’ve already posted an article on building a whitebox VMware vSphere server for your home lab (click here), otherwise you can always use VMware Workstation on your PC or laptop.

Installing vMA

Installing the vMA is very easy and you can download the latest version from VMware where you will also find documentation. It will download in .zip format and contains the vMA as an OVF. This can be imported into vCenter ‘File > Deploy OVF Template…‘.  Once it has been deployed into your vSphere environment and powered on, you will be presented with a text based setup wizard where you can set the IP address, subnet mask, gateway, DNS, and so on. When you have completed the setup, you will need to connect to the vMA using an SSH client (PuTTY).

Getting started with vMA

Log into a the vMA using vi-admin and the password you created during the initial setup. As I mentioned previously, vMA has all of the vCLI commands (E.g. vicfg-nics, vicfg-vswitch) which are located in /usr/bin.

With any command remember that you can use --help (E.g. vicfg-nics --help) to display a list of options, even seasoned command line junkie’s use this so don’t think of it as something just for us newbies!

Most commands will need a target server, so here is an example of a simple command you can try out on one of your hosts. Throughout this article I will be using my own home lab to run these commands.

$ vicfg-nics -l --server esx01.home.lab (Always use the FQDN of your host)

It will prompt you for a username and password that you can use to authenticate against this host, for our example we are using root. You will then see your NIC’s listed:

Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 02:00.0 e1000 Up 1000Mbps Full 00:50:56:a5:00:07 1500 Intel Corporation PRO/1000 MT Single Port Adapter
vmnic1 02:02.0 e1000 Up 1000Mbps Full 00:50:56:a5:00:03 1500 Intel Corporation PRO/1000 MT Single Port Adapter

As you can see this is a really easy way of managing your ESX hosts, but another feature you should be aware of is the vi-fastpass which allows you to add your hosts and vcenter server with the associated passwords. With vi-fastpass you can run the vicfg commands without being prompted each time. Very slick.

To use vi-fastpass you need to add the hosts you wish to manage using the vifp addserver command:

$ vifp addserver

Next you need to set your target using the vifptarget command:

$ vifptarget -s esx01.home.lab

Note: The vifptarget command has replaced vifpinit. Watch out for this if you are studying for your VCAP-DCA exam.

You’ll notice that the shell prompt now has the hostname of your target host, very useful if you forget which target you last set!

[vi-admin@vma ~][esx01] $

If you run the vicfg-nics -l command again you won’t be prompted for the root password.

Session Files

Another method of storing the host credentials is with session files. I personally don’t use this because I prefer vi-fastpass, but it is good to understand how it works. Firstly, change directory to /usr/share/doc/vmware-vcli/samples/session and you’ll see three Perl scripts:

$ cd /usr/share/doc/vmware-vcli/samples/session
$ ll

-r-xr-xr-x 1 root root 782 Apr 8 2010 load_session.pl
-r-xr-xr-x 1 root root 2624 Apr 8 2010 multisession.pl
-r-xr-xr-x 1 root root 888 Apr 8 2010 save_session.pl

Creating a host session

# ./save_session.pl --server esx01.home.lab --username root --password Password --savesessionfile /home/vi-admin/esx01.session

The above command will create a file in /home called esx1.session and stores the credentials for that host. It doesn’t store the password in plain text, and it only lasts for 30 minutes unlike vi-fastpass.

To test your session file, first make sure your vifptarget is clear then run the vicfg-nics command using the session file:

$ vifptarget -c
$ vicfg-nics -l --sessionfile /home/vi-admin/esx01.session

The command should run without prompting you for a password.

Summary

Now that you can see how easy it is to get started with vMA, I recommend that you download the documentation from VMware and experiment with different commands. In addition to adding ESX/ESXi hosts with vifp addserver, you can also add vCenter servers. To display a list of your servers use vifp listservers.

Here is a very quick and dirty tech tip on changing the IP address of your VMware vMA. There are two ways of doing this, the Linux way or the VMware Setup Wizard.

Method 1: The Linux Way

Using your favorite text editor (Vi in my case) edit the following file using sudo:

# sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

You should see something similar to the following:

DEVICE=eth0
BOOTPROTO=static
PEERDNS=no
ONBOOT=yes
IPADDR=192.168.4.42
NETMASK=255.255.255.0
GATEWAY=192.168.4.1

Make the necessary changes and write-quite (:wq)

Restart the network service:

# sudo service network restart

Method 2: Using the vMA Setup Wizard

Change the working directory to /opt/vmware/vma/bin/

# cd /opt/vmware/vma/bin/

Run the vmware-vma-netconf.pl script:

# sudo ./vmware-vma-netconf.pl

Follow the on-screen instructions. Job done.

VMware HA (High Availability) admission control is something I wanted to understand better so I started making notes gathered from various sources on the subject, and in particular the way slot sizes are calculated. Duncan Epping’s Yellow Bricks site already covers HA very well and I bow down to his knowledge on the subject, well worth checking out. Also I would strongly recommend VMware vSphere 4.1 HA and DRS Technical Deepdive by Duncan Epping and Frank Denneman which I purchased at Comcol.nl which they shipped to me in the UK in just two days.

That said, I thought I would share my own views and notes I have taken on the subject. The vSphere Availability guide states “A slot is a logical representation of memory and CPU resources. By default, it is sized to satisfy the requirements for any powered-on virtual machine in the cluster.” – In simple terms a slot can be consumed by a single virtual machine, but a virtual machine may consume more than one slot.

When you create an HA enabled cluster, the default admission control policy is set to “Host failures cluster tolerates”. It is important to understand how this works to avoid any ‘schoolboy errors’ or mis-calculations in your design.

Rule # 1: Remember this, “The hostess with the mostess” – the ESX host with the most available slots will be taken out of the equation when calculating HA admission control. If your ESX cluster has 6 hosts with 16GB memory, and one host with 32GB memory then this will be excluded from the calculation.

Calculating the Slot Size (memory and CPU)

Firstly, do any virtual machines have a reservation on the CPU or memory? If so, then the virtual machine with the largest reservation on a given host is taken into account. For virtual machines that have no reservations, the slot size is calculated with the CPU at 256Mhz and memory at the VM overhead (E.g. 123.73MB – See page 28 of vsp_41_resource_mgmt.pdf). Repeat this for the remaining virtual machines on the host (see flowchart).

Flowchart Example

Lets say that we have 10 virtual machines (1 vCPU each) and two of them have reservations as follows:

VM 1 – Has a CPU reservation of 700Mhz, and no memory reservation.
VM 2 – Has a CPU reservation 500Mhz and memory reservation of 1024Mb.
VM 3 to 10 – No reservations on memory or CPU. (keeping this example simple)

The slot size calculation will take the largest reservation for memory and CPU. In this example the result would be:

CPU: 700Mhz
Memory: 1147.73MB (1024Mb plus overhead)

Rule # 2: Remember that the biggest reservation will be used for memory and CPU. If no reservations are set, then it will use 256Mhz for the CPU and 0MB + virtual machine overhead for the memory.

Calculating the Number of Slots Available

Now we have the slot size for our ESX host, the next step is to work out how many slots we have. In order to calculate this, simply divide the CPU and memory available on the host by CPU and memory slot size. For example, using our figures above (700Mhz and 1144.73Mb), say our host has 5934 Mhz CPU available and 7126MB memory, our slot sizes will be 8 for the CPU and 6 for the memory.

5934 /700 = 8
7126 / 1147.73 = 6

Result: Take the smaller of the two, and our ESX host has 6 available slots. Do this for each host in the cluster and you have the total number of slots available in your cluster (minus the host with the most slots).

Rule # 3: It will always use the smallest number of slots from CPU or memory.

What Does This All Mean?

Now we understand how slots are calculated on each of our ESX hosts, it gives us a better insight when determining how your HA will be configured. Here is a simple check-list of questions you should ask yourself:

• Do any of my virtual machines  have CPU or memory reservations set?
• Are all of my ESX hosts of the same specification, or do I have one or two with significantly more CPU or RAM?
• How many host failures do I need to tolerate?

Some possible solutions:

• Don’t use virtual machine reservations unless absolutely necessary, instead use resource pools with reservations as these are not used in the slot size calculation.
• Keep the hosts in your cluster of similar specification (same CPU and memory) otherwise it could be eliminated when calculating the number of slots to use.
• Do you need an HA policy based on a number of host failures?   Use ‘Percentage of cluster resources reserved as failover spare capacity’.

If you are involved in DR for your organisations IT infrastructure and are replicating virtual machine VMFS datastores then you may be familiar with DisallowSnapshotLUN in ESX 3.x. Let’s start with a background on what these advanced settings are and why they are there.

Since virtualization changed the landscape for disaster recovery  some time ago now, most businesses have embraced SAN storage replication for DR (see my other post). This is old news now, but unless your SAN vendor integrates with something like VMware Site Recovery Manager (SRM) then you will have a number of manual tasks involved in your DR recovery process.

When you replicate your datastores (or LUN’s) from site A to site B, you will be using an asynchronous mirror between these two sites. In other words, data blocks will be scheduled (or queued) for replication to site B. If it was synchronous then as data is written to disk, the write operation wouldn’t be acknowledged until it is written to both disks or arrays. Obviously synchronous replication would be far too slow across a WAN to a DR site.

In order to use the replicated LUN in your DR site, you will need to take a snapshot of the replicated LUN then present the snapshot LUN to your VMware ESX hosts in the DR site. Different SAN vendors will have slightly different methods and management capabilities, but the underlying requirement doesn’t change. Without modifying the advanced settings of your ESX 3.x host you will not be able to present your snapshot LUN (VMFS datastore) to the ESX host.

ESX 3.x: What you’ll need to do is set the following parameters:

EnableResignature=0
DisallowSnapshotLUN=0

By switching off DisallowSnapshotLUN, the ESX host will allow your replicated LUN to me added and it won’t re-signature the volume. By default DisallowSnapshotLUN is set to 1. You can find this setting in the Configuration tab of the ESX host > Advanced Settings.

ESX 4.x:

VMware already have a KB article on this here: kb.vmware.com/kb/1011387

It says that you can just use the Add Storage wizard and it will display the VMFS label. If it’s not mounted then you can assume it is a snapshot (or volume copy) and can go ahead and mount it. Using the GUI will force-mount a VMFS volume and also  make it persistent. In fact the advanced settings (EnableResignature and DisallowSnapshotLUN) are no longer present with ESX 4.x.

Useful KB Articles:

kb.vmware.com/kb/1003641 – Cannot access the LUN as it is marked as a deactivated snapshot
kb.vmware.com/kb/6482648 – VMFS Volume Can Be Erroneously Recognized as a Snapshot
kb.vmware.com/kb/1015986 – Force mounting a VMFS datastore residing on a snapshot LUN results in the error: Cannot change the host configuration

Creating a Remote Desktop Gateway (RD Gateway) is straight forward and can be used to securely access your Windows servers over port 443 using the Remote Desktop Connection Client.  I use this to access my home lab when I’m on the road or at work, and it saves exposing your machines to the internet directly over RDP (TCP 3389). The RD Gateway isn’t new, in fact it was available on Windows Server 2008 as TS Gateway, and the installation is the same. For this article, I will be using Windows Server 2008 R2.

I run my RD Gateway on a virtual machine located inside a DMZ that I have created using Vyatta, a free virtual appliance. I won’t go into the firewall configuration here, as this is a quick configuration guide for creating your RDS Gateway.

Step 1: Build a new virtual machine and install Windows Server 2008 R2.

Step 2: Click on Add Roles (in Server Manager). You will then be presented with the following wizard dialog boxes. Click on each image for full screen.

a) Click next

b) Select “Remote Desktop Services” and click next

c) Click next

d) Select “Remote Desktop Gateway and click next”

e) Click “Add Required Role Services”

f) Select “Choose a certificate for SSL encryption later”

g) Select “Create authorization policies”  ”Now” and click next

h) Add the group(s) that you wish to grant access through the RD Gateway or leave the default “Administrators” and click next

i) Leave the default “Password” selected and click next

j) Click “Browse” to choose which computers RD Gateway users can connect to, or select “Allow users to connect to any computer on the network” and click next

k) Click next on the “Introduction to Network Policy and Access Services” screen

l) Leave the default “Network Policy Server” selected and click next

m) Click next on the “Introduction to Web Server (IIS)” screen

n) Leave the defaults selected and click next

o) Click Install to begin the installation.

When the installation is finished you should be presented with the following screen:

Step 3: Configuring the RD Gateway

1. Now the RD Gateway is installed, go to Start > Administrative Tools > Remote Desktop Services > Remote Desktop Gateway Manager.
2. Right click on the RD Gateway server within the RD Gateway Manager console and select Properties.
3. Select “Create a self-signed certificate” then click “Create and Import Certificate”. You will then be presented with the following:
4. Make sure that the certificate name is the internet DNS (domain) name that resolves to the internet IP address of the RD Gateway server. The firewall will need to allow communication to the server on TCP port 443.
5. Tick “Store the root certificate” and choose a file location to save the certificate. For example: C:\rd-cert.cer

As this is a self-signed certificate, you will need to import the certificate to your machine that you are accessing the RD Gateway from. To do this, follow these steps:

1. From the client machine accessing the RD Gateway, right click on the certificate file and click “Install Certificate”
2. Click Next then select “Place all certificates in the following store”
3. Browse to “Trusted Root Certification Authorities”, then click Next.
4. Click Finish

Note: You will need to ensure that the internet (DNS) host name can be resolved to the internet IP address of the RD Gateway server, so make sure that this is the case. This domain name must match the certificate name (E.g. rdg.mydomain.com)

Step 4: Configuring the Remote Desktop Connection Client

1. Launch the Remote Desktop Connection client.
2. Select the “Advanced” tab and click “Settings”.
3. Select “Use these RD Gateway server settings” (Windows XP will be “Use these TS Gateway settings”)
4. Enter the server / host name (E.g. rdg.mydomain.com) of your RD Gateway server
5. Optional: Select “Use my RD Gateway credentials for the remote computer”
6. Click OK.
7. Finally, under the “General” tab enter the local IP address or server name of the machine you wish to connect to.

Your connection will be tunnelled over SSL, providing your firewall configuration permits TCP port 443 from the internet to your RD Gateway server and TCP port 3389 from the RD Gateway server to your internal network.

The third part of this series continues with the vSphere build on my whitebox server, the Asus Rampage II Extreme with Intel Core i7 2.8Ghz and a 120GB SSD. Following on from the video in part 2 where we installed ESXi on to the USB drive, we are now ready to access the physical ESXi host and start creating some virtual machines.  Since this is a home vSphere lab environment, accessing the lab from anywhere (not just at home) is a major advantage for me, so I’ll be taking you through the steps to create a Microsoft Windows Server 2008 R2 virtual machine with an RD Gateway (Remote Desktop Gateway). We will also need shared storage in order to use vMotion, so I will also guide you through the setup of an OpenFiler iSCSI virtual SAN.

Part 1 | Part 2 | Part 3

To Do List:

If  you have followed part 2 then your physical ESXi host should be up and running and sitting in your garage, shed, spare room (wherever its new home is!). You can now switch on your laptop or desktop PC, get a warm drink and we will get the vSphere lab configured!

Note: I’d also like to mention that whilst I decided to install VMware ESXi 4.1 to a USB drive, there is no reason you can’t install the full ESX 4.1 (with Service Console) to the local SSD drive.

• Download and install the vSphere client
• Creating the core virtual machines:
  • Domain Controller
  • vCenter server
  • RD Gateway
  • OpenFiler SAN
• Finally create virtual ESXi hosts.

vSphere Lab Environment Topology:

A note on licensing

You will also notice that the ESXi server will automatically assign a 60-day evaluation license. Although you can register for a free ESXi license, the free edition will be extremely limited in features and totally unsuitable unless you simply wish to run virtual machines.

I will be assuming that all licenses for your home lab will either be evaluation or purchased. The downside of evaluation licensing of course is that you’ll have to re-install your environment every 60 days.

Download and Install the vSphere Client

1. Navigate to https://<ESXi-IP-ADDRESS> (E.g. https://192.168.4.10)
2. Download vSphere Client and install!

When you launch the vSphere Client, you’ll need to enter the IP address of the ESXi host followed by the username (root) and password. You should have this information following the installation and initial configuration in part 2. You will receive a security warning stating that the SSL certificate is untrusted.

3. Select “Install this certificate and do not display any security warnings” then click Ignore.

Creating the core virtual machines:

I’ve called these the ‘core’ virtual machines as these are the VM’s that make up the home lab and provide the core functionality. I won’t be guiding you through the steps to create virtual machines, as this article is aimed at someone with at least a basic understanding of creating a VM, however, I will be summarising the configuration required.

The following specifications are well below the recommended, however, this is what I have used in my lab environment and it works well for me. All virtual machine hardware is version 7.

I created a domain controller on Windows Server 2008 R2 and added (A) records for CORE-ESX, and ESX01 – 05. Nothing more to this stage.

Build a virtual machine running Windows Server 2008 R2 and join it to your domain. Next, install vCenter with Microsoft SQL 2005 Express. I won’t detail the steps required to install VMware vCenter, just follow the installation defaults.

The RD Gateway server enables me to securely connect over port 443 to any of my machines. It only takes a few minutes to setup, and it gives me the flexibility to connect from anywhere. Read my article on installing and configuring the RD Gateway here.

Installing & Configuring the Openfiler SAN:

The Openfiler SAN is a virtual appliance and can be downloaded from www.openfiler.com. As a virtual appliance you just need to upload it to your datastore and add it to the ESXi server (browse datastore and add to inventory), no configuration of the virtual machine hardware is necessary. For your information here is the configuration of the Openfiler:

I’ll be adding a guide to the Openfiler setup soon, but I’m slacking due to the Christmas and New Year break (that’s my excuse anyway!)

Part 1 | Part 2 | Part 3