VMware ESX(i) 4.0 (vSphere) -Connecting to an iSCSI Storage Target.

With a complete re-write of the iSCSI portion of the code, ESX 4(vSphere) provides better performance and useful features such as Jumbo Frame support and TCP Segmentation Offload (TSO).  There is more reason than ever to consider iSCSI based share storage to house your VMs.

There are many low cost iSCSI storage solutions available such as OpenFiler of which I have written a configuration article here.

Here is a quick guide to assist you on your way to connecting your ESX(i) 4.0 host to an iSCSI source.  Many of these screenshots are self explanatory so I will keep my descriptions to a minimum.

Initially you will most likely only have a ‘Management’ and a ‘Virtual Machine Network’ as you’ll need to have a dedicated network connection for the iSCSI traffic (between the ESX host and the iSCSI target) then…

… from the ‘Configuration’ –> ‘Networking’ screen select ‘Add Networking’.

Select ‘VMkernel’ as the ‘Connection Type’.

Select the NIC(s) you want to use for your iSCSI VMKernel connection (ensure that it has network connectivity through to your iSCSI target ideally on its own separate network segment – this is strongly advised).

Type in a meaningful ‘Network Label’ none of the other options are required so leave them unchecked.

Give your new iSCSI network connection a IP address.  As a dedicated network is strongly recommended for iSCSI traffic ensure that it is given a unique IP address on the same subnet as your iSCSI target.  As this traffic will not be leaving this dedicated network then there no need in this example to specify a new gateway.

After configuring this new iSCSI VMKernel port you will now see it displayed in the ‘Networking’ area of the ‘Configuration’ section.  As you can see I am only using a single NIC meaning that this is potentially a single point of failure.  If you are considering using iSCSI in a production environment then you would ideally want to use multiple NICs for extra resilience.

Now select ‘Storage Adapters’ from the ‘Configuration’ menu.

As outlined in the screen shot below select the ‘iSCSI Software Adapter’ and then click on ‘Properties’.

You’ll notice that by default the status of the ESX iSCSI software initiator is set to ‘Disabled’.  We want to change this.. (see steps below)

You’ll notice that when you enable the iSCSI initiator a rather long name will be auto generated in the ‘iSCSI Name’ field.  This is a unique name that only your ESX host will have.  It can be changed to something else of your choosing though just make sure that it is unique.  I personally always leave them with the auto generated iSCSI name.

Now select the ‘Dynamic Discovery’ tab and press the ‘Add’ button as we now want to tell our ESX host where to find the iSCSI target.  In the ‘iSCSI Server’ field enter in the IP address of your iSCSI target – you shouldn’t have to change the default port number.

Depending on the level of security set on your iSCSI target you may have to enter in the ‘CHAP’ authentication details.  Talk to the person who configured your iSCSI target to see if you need to do this..

Once you’ve added in the details of your iSCSI target you’ll see it’s IP address appear in the ‘Send Targets’ list.

You’ll also be prompted to rescan the Host Bus Adapter (HBA).  Select ‘Yes’ as you want your ESX host to go and try to connect to your specified iSCSI target.

Everything going to plan and you should now see your iSCSI target (in this case my OpenFiler) appear in the ‘Storage Adapters’ configuration screen.  This means that it has connected through successfully.

This next step will vary depending on whether your iSCSI storage has VMFS applied to it already or not.  If it hasn’t and this is fresh new disk presented to the ESX host then you’ll want to format it with VMFS to allow VMs to be stored on it.  Else if it has already been configured with VMFS then this iSCSI storage will automatically appear for use to your ESX host (see below).

You will now be all set to go. Enjoy!

Good Zeus ZXTM and MS ISA Blog

A friend and colleague Antony Joyce runs an informative blog called ‘ClusterFunk’ (.co.uk).  It is predominantly focused around the traffic management (ie: load balancer and reverse proxy) product from Zeus called ZXTM (Zeus Extensible Traffic Manager) though he does have other good articles relating to MS ISA and the like.

Well worth heading over for a look if you use, or are just interested, in any of these products or technologies.

How to copy or move files and folders whilst maintaining their original time date stamp.

It’s often useful when try to replicate live file data to maintain the date/time stamp of the data you are copying or moving.  As you no doubt know a standard copy whether it be from the command line or by a simple drag and drop will give any copied/moved files a new date/time stamp of the current time.

A simple way of maintaining the original date/time stamp of a file or folder is by using the ever useful  Microsoft RoboCopy utility.  This is built into Windows Server 2008, Vista and Windows 7 as standard though if you are running an earlier Windows OS (eg: XP or Windows Server 2003) it can be found, and used, as part of the Windows Server 2003 Resource Toolkit which can be downloaded from here.

Below is an example of the Robocopy syntax that you’d use:

Links – Microsoft SharePoint with SQL DB Mirroring and Failover

Here’s a collection of good SharePoint SQL database mirroring links and articles I have found to be useful specifically around the area of failing over MOSS.

• Microsoft SharePoint Team Blog: Configuring Database Mirroring for SharePoint Products & Technologies – contains a link to the useful ‘Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services’ document.
• Ask Core: SharePoint Content DB Mirroring for DPM Administrators – has a very good step by step MOSS DB mirroring, including failover, video.
• SharePoint University: Database mirroring failover script.
• Code Prostitute: Using SQL Alias for failover with Sharepoint (SPS 2007).
• Michael Nemtsev: SharePoint Mirroring.

Link – PHP Basics Tutorial for WordPress Users

This ended up being quite a find for someone like myself who runs their blog on WordPress but has no clue when it comes to PHP.  I wanted to make a couple of minor tweaks to the code of the site and found the information in this basic PHP tutorial by Adam Brown valuable and thought it worth a mention.

So if you, like me, have limited knowledge of PHP and are thinking of having a dabble on your WordPress press site or similar  it’d be well worth checking it out.

How to Provide Management and General VM Network Resilience with only 2 Physical NIC’s on vSphere ESXi 4.0

Wow, that was quite a lengthy title for this post but I felt it described it accurately.   

This article is in response to a recent query I had regarding providing network resilience for Management and General VM networks on VMware ESXi 4.0 (also applies to ESXi 3.5) when you only have two physical NICs.  Please note that this article applies to ESXi and not ESX (minus the i).  As you probably know ESX (minus the i) has the requirement of an additional port for Service Console (SC) traffic.

In this example I am using a Dell PowerEdge R710 which actually comes with four x 1Gb ports on the back though for the purposes of these examples I have only connected two of the physical NICs ports.  Servers such as the HP Proliant DL360 G5/G6 as default only come with two x 1Gb ports and with tight budgets there may not be the luxury of purchasing additional network ports via a PCIe expansion card.

Following VMware’s best practice (see VI Performance Turning Guide, pg 7) of having a dedicated Management and VM Network port (and with the full fat version of ESX a Service Console (SC) port) each of which would also have a level of resilience in the form of an additional failover port(s) we would ideally need 4 physical network ports for a standard non iSCSI or vMotion enabled ESX host (see below):

Some people use VLAN’ing to separate their networks when presented with limited physical ports in a ESX host though often what you see is the configuration in the screenshot below where the Management and VM Networks are on separate physical NICs.  In the unlikely event that one of these fails then connectivity to that particular Port Group will be lost.

Rather than the two Port Groups sharing the two physical NICs and using VLAN’ing to separate the traffic of each there is any easier way of providing network resilience to a two NIC ESX host. 

First of all you have to add both the ‘Virtual Machine’ (VM Network) and ‘VMKernel’ (Management Network) to a single Virtual Switch.  Then to this Virtual Switch add the two physical adapters/NICs.  You should end up with a configuration below:

Next we want to specify which of the two physical NICs will be the ‘Active’ and ‘Standby’ Adapters for each of two Port Groups. It doesn’t really matter what order this is done in though for this example I am selecting the ‘Management Network’ after pressing the ‘Properties’ button (see screenshot above).

After selecting to edit the ‘Management Network’ and clicking on the ‘NIC Teaming’ tab you should see both NICs as being ‘Active Adapters’.  Take note of which NIC (eg: vmnic1) you are moving and using the ‘Move Down’ button make it a ‘Standby Adapter’ for the ‘Management Network’.

After making this change all of your ‘Management Network’ traffic will run over ‘vmnic0’ though should this connection fail due to network port  or cable failure then it will use ‘vmnic1’.

Next you want to change the NIC adapter Active/Standby order for the ‘Virtual Machine Network’.  Follow the same procedure as outlined above though…

…when you get to specifying which is the ‘Active’ and ‘Standby’ adapter ensure that these are the reverse of what you specified for the ‘Management Network’ port group (ie: ‘vmnic1’ should be the ‘Active’ and ‘vmnic0’ the ‘Standby’.

After completing this the ‘Management Network’ or the ‘Virtual Machine Network’ Port Group traffic are running over separate physical NIC ports though they can now withstand a single physical NIC failure.  In the event of this occurring both lots of traffic will be travelling over the same physical NIC port though this is much better than any service downtime and also gives you time to resolve the issue.

To eliminate another single point of failure it is a good idea to have each of the physical NICs ports patched into separate physical switches.