For HP, it is supported on P4000 (Lefthand), P6000 (EVA) and P9000 (XP).  For VASA to function, you will need to install an additional component from HP called HP Insight Control Storage Module for vCenter.  The current version at moment of writing is 6.3.1.  And yeah, it’s free

The architecture looks like this:

In this example, we will install it on a seperate server called VASA.labo.local in our Ultimate vSphere Lab.  I already have a P4000 VSA running in that lab on a seperate iSCSI network.

Make sure the VASA server can communicate with the SAN AND the vCenter.  In my lab, i had to give it 2 vNICs since the SAN is on an isolated network.

From the VASA server, start the setup of HP Insight Control for vCenter.

Accept all the default but only select to install the Storage module.

The installation will start the Storage Module after a while.

For the Credentials, specify the Allow all vSphere client credentials option:

Do not import any existing data in the vCenter database (because it’s a new installation).

When installation is complete, start the Insight Control for vCenter application (shortcut on the Desktop).  A website will pop up. (https://localhost:50025/setupwizard)

Fill in Administrator credentials.  A wizard will pop up.

Click Next after verifying the VASA hostname.

Fill in the vCenter details and Add it.  Click Next.

Since i don’t have HP SIM, leave all HP SIM fields blank and click Next.

Fill in the ESXi Host credentials and click Save.

Configuration is complete!

Next, open up Storage Administrator Portal (https://vasa.labo.local:3508) and log in.

Click the Add button to add an array.

We will configure HP P4000.

Fill in the IP and credentials for the Lefthand VSA.

It will recognize your Management Group (meaning connection was successful).

We won’t be playing with provisioning, so Full Access isn’t necessary, but i will provide it anyway since it is a Lab environment.

Fire up vSphere Client.  You will get a certificate warning about the VASA server.  Install the certificate and Ignore the warning.

Go to Home – Administration – Storage Providers and click the Add button.

Name the Vendor Provider HPICSM and link it to https://vasa.labo.local:3518/vasa_provider_ws/vasaService.  Replace the servername with the servername you installed HP Insight Control on.  Pay attention to the port number which is 3518.

Click Yes in the Security Alert windows.

The Vendor will be added to the list in vSphere Client.

Now you’ll have to be patient as the data will be collected through VASA in the background.  After a while, when you click a Datastore under Configuration, it will have the System Storage Capability filled in:

To test, i also created a Thick volume on the P4000 SAN and it shows up clearly:

Since we now have this info, we can easily create a VM Storage Profile for all Thin P4000 volumes.

If you now create a new VM, my Lefthand Thin VM Storage Profile will only list datastores backed by Thin provisioned volumes on the P4000.

Pretty cool stuff!

Those machines come equipped with 4 PSUs.  When the power is lost of 2 PSUs at the same time, a reboot is triggered by the HP Agents.  This causes all VMs on that host to crash (HA will restart them on another host if configured properly).  This reboot makes no sense as the system is perfectly capable of running on 2 PSUs.

The messages logfile show the following events:

— hpasmlited[7216]: CRITICAL: System Power Supply: General Failure (Power Supply 1)

— hpasmlited[7216]: WARNING: System Power Supplies Not Redundant

— hpasmlited[7216]: CRITICAL: System Power Supply: General Failure (Power Supply 3)

— hpasmlited[7216]: A System Reboot has been requested by the management processor in 60 seconds.

If the power is lost on 2 PSUs with a pause in between (we tested with 30 seconds), the reboot is NOT triggered.

I don’t know if this bug is specific to our environment and/or to ESX, but i strongly suggest to test this if you have DL 580 G7 hosts running ESX(i).  Pull the power from 2 PSUs and monitor the messages logfile for any reboot messages.

As a workaround, you can stop the hp-health services (leaving you blind for the time being because you don’t have hardware monitoring) or pray to god that 2 PSUs won’t fail at the same time

HP confirmed this as a bug and it will be solved in the next release.

It is however possible to use EFI instead of BIOS.

The vSphere Installation and Setup guide states that you shouldn’t change the boot type from BIOS to EFI on an already installed ESXi host.  It does work however in VMware Workstation.  But for production systems, just stick to the guide and reinstall the host using EFI instead of BIOS on your hardware server.

Now, your normal Virtualized vSphere host in VMware Workstation uses a BIOS.  Notice this in the startup screen when you boot the VM:

Power down your Virtual ESXi host.  Go to the location where the vmx file is stored and edit it with your favorite editor.

Add the line firmware = “efi” somewhere in the vmx file.

Close and save the vmx file.  Power On the ESXi host.  You’ll notice the progress bar at the bottom during the boot is gone:

If you look into the vmware.log you can also see some references that he’s using EFI now:

Et voila, your ESXi hosts are now booting from EFI instead of BIOS!

Tip: if you press ESC during the boot, you can configure some EFI parameters.  Play with it and learn to know if since EFI will replace BIOS gradually!

Open a Command Prompt and cd into the directory where VPXClient resides (Program Files\Infrastructure\Virtual Infrastructure Client\Launcher).

Start vpxclient.exe –locale xx where xx is one of the following:

So if you want to start vSphere Client in Japanese, start vpxclient.exe –locale ja.

And this gives you a Japanese vSphere Client.  I don’t dare to click anything as it’s all Chinese  euhm, Japanse to me

Enjoy!

Let’s create a new VMnet5 network in the Virtual Network Editor.  Use range 10.0.3.0/255.255.255.0 and enable the Use local DHCP service to distribute IP address to VM.

Change the DHCP Settings and fill in a valid start and end address.

Power Off the ESXi hosts and give them two extra vNICs attached to VMnet5.

Create a new Virtual Machine portgroup/vSwitch on vmnic6 & vmnic7 and you’re set:

Now you can start creating your VMs, vMotion them around, play with Fault Tolerance, create dvSwitches, install VDR, experiment with vShield Zones, …  you get the picture

With this we can finalize this series.  You now have a fully functional environment which is very flexible and you can start playing with all the features in vSphere 5!

Happy playing in your Virtual Lab Environment!

Building the Ultimate vSphere Lab – Part 1: The Story

Building the Ultimate vSphere Lab – Part 2: The Hardware

Building the Ultimate vSphere Lab – Part 3: VMware Workstation 8

Building the Ultimate vSphere Lab – Part 4: Base Template

Building the Ultimate vSphere Lab – Part 5: Prepare the Template

Building the Ultimate vSphere Lab – Part 6: Domain Controller

Building the Ultimate vSphere Lab – Part 7: SQL Server

Building the Ultimate vSphere Lab – Part 8: vCenter

Building the Ultimate vSphere Lab – Part 9: ESXi

Building the Ultimate vSphere Lab – Part 10: Storage

Building the Ultimate vSphere Lab – Part 11: vMotion & Fault Tolerance

Building the Ultimate vSphere Lab – Part 12: Finalizing the Lab

Let’s take a look at vSwitch0 first:

Open Properties… and remove the VM Network portgroup.  Then, open the properties of the vSwitch and put both vmnic adapters as active.

Now open the properties of the Management Network and set vmnic0 as active and vmnic1 as standby.

Now, add a new VMkernel interface on vSwitch0.  Name it vMotion and enable it for vMotion.

Use IP 10.0.0.11/24 for ESXi1 and 10.0.0.21/24 for ESXi2.

Finish the wizard, open the Properties of the vMotion Portgroup and set the NIC order so vmnic1 is active and vmnic0 is standby.

Repeat this procedure for ESXi2.

That’s it for vMotion.  Not really rocket science

Now it’s time to activate Fault Tolerance.  That’s right, Fault Tolerance running on vSphere in VMware Workstation!

Power Down your two ESXi hosts.

Open the Virtual Network Editor and create a VMnet4 network in the 10.0.2.0/24 range.

Give each ESXi host 2 new Network Adapters in this VMnet4 network.

Power On the hosts and get into Configuration – Networking.

Click Add Networking… to add a new vSwitch.  Select VMkernel and use vmnic4 and vmnic5.

Name it Fault Tolerance and enable it!

IP will be 10.0.2.10/24 for ESXi1 and 10.0.2.20/24 for ESXi2.

This gives you the following Networking Layout.

Now, before you enable FT on a VM, you need to set the following Advanced Configuration Parameters on EACH VM you want to protect with FT.

replay.allowBTOnly = true

replay.allowFT = true

replay.supported = true

Now you can run Fault Tolerance enabled VMs on your virtual vSphere 5 ESXi hosts!  How cool is that?  One exception though, the VM you enable for FT can be 32-bit only!

I personally like to play around with some DOS appliance which has some games installed.  It is small enough to run smoothly on these virtual environments.

Building the Ultimate vSphere Lab – Part 1: The Story

Building the Ultimate vSphere Lab – Part 2: The Hardware

Building the Ultimate vSphere Lab – Part 3: VMware Workstation 8

Building the Ultimate vSphere Lab – Part 4: Base Template

Building the Ultimate vSphere Lab – Part 5: Prepare the Template

Building the Ultimate vSphere Lab – Part 6: Domain Controller

Building the Ultimate vSphere Lab – Part 7: SQL Server

Building the Ultimate vSphere Lab – Part 8: vCenter

Building the Ultimate vSphere Lab – Part 9: ESXi

Building the Ultimate vSphere Lab – Part 10: Storage

Building the Ultimate vSphere Lab – Part 11: vMotion & Fault Tolerance

Building the Ultimate vSphere Lab – Part 12: Finalizing the Lab

We will go for an iSCSI solution.  This makes perfect sense since this can be virtualized perfectly.  Many iSCSI appliances exist on the market today.  Lefthand, UberVSA, OpenFiler, …  I will however go with the easiest solution: installing a Software iSCSI Target on Windows Server.

Again, various flavors exist, but what most people don’t realize is that Microsoft has it’s own free iSCSI Target.  I has all the basic functionality you need (CHAP, Snapshots, …).  No replication or other advanced stuff is supported, but we don’t really need that for now.

Let’s start by downloading the goodies: http://www.microsoft.com/download/en/details.aspx?id=19867

Extract it and put it on the Shared Folder to the VMs can access it.

Now, before we install the iSCSI Software, we need to change our VM to support it.  We will use our vCenter Server for Storage.  If you have the resources on your PC, a dedicated VM would be better (but then, i would go for a dedicated iSCSI appliance like Lefthand, OpenFiler, …).

Give your vCenter VM a second Hard Disk of 500GB and put it on HDD storage.

Initialize it in Windows.  That will become our E: drive on the vCenter:

Now, we want our iSCSI to be a seperate network.  So open the Virtual Network Editor in VMware Workstation.

Create VMnet3 for IP range 10.0.1.0/24.

Give the vCenter VM a Second Network Adapter connected to this newly created network.

On the vCenter, rename the connection to iSCSI.

Give it IP 10.0.1.3/24.

Go to the Microsoft iSCSI Software Target folder and start x64\iscsitarget_public.msi.

The installation is a matter of Next, Next, Finish.

Now, open the Microsoft iSCSI Software Target console.

On the root item, click Properties.  Enable only IP 10.0.1.3 to listen for iSCSI sessions.  This ensures we only use the dedicated iSCSI network (VMnet3).

Right-click Devices and select Create Virtual Disk.

Point it to E:\iSCSI\Datastore1.vhd.

Set it to 200GB (200000 MB) or something in that neighborhood.  Pay attention as the input fields are in MB (Megabytes).  We won’t assign any targets yet.

Create a second Virtual Disk called Datastore2 in the same folder.  Make the size different, so it’s easier to differentiate the two datastores.

Now that we have our storage ready, let’s prep the ESXi hosts for it.

Remeber that we put the iSCSI traffic on a seperate VMnet3 network.  Our ESXi hosts currently have 2 NICs in the VMnet2 network, so no iSCSI traffic will be possible.

Shutdown the ESXi hosts, go into Settings and Add 2 Network Adapters both connected to VMnet3.

Power On the ESXi hosts.  Select a host and go into Configuration – Networking.  Your current config will look like this:

Click Add Networking… to add a new vSwitch.

Select VMkernel as the type.  Use the newly added vmnic2 & vmnic3.

Name the Portgroup iSCSI_1 and don’t select any other options.

Use IP 10.0.1.10 for ESXi1 and 10.0.1.20 for ESXi2.

Open the Properties of vSwitch1 and select Add… to add another VMkernel interface.  This will become iSCSI2 with IP 10.0.1.11 for ESXi1 and IP 10.0.1.21 for ESXi2.

Change the NIC Teaming Failover order of both iSCSI_1 & iSCSI_2.  Set vmnic2 active for iSCSI_1 where vmnic3 becomes unused.  Change it the other way around for iSCSI_2.

The Network Layout looks like this now:

Now get into Configuration – Storage Adapters and click Add….

Select the newly added iSCSI HBA (vmhba33) and click Properties….

Copy the iSCSI Name (you can change this name to something more readable if you want)

Get back into the Microsoft iSCSI Software Target console and select iSCSI Targets – Create iSCSI Target.

Fill in the hostname as the iSCSI target name:

Paste the iSCSI Name from vCenter into the IQN Identifier field.

Now that the Target is created, let’s assign our two LUNs to it.  Right-Click it and select Add Existing Virtual Disk to iSCSI Target.

Select both disks.

Back in vCenter, open Network Configuration on the iSCSI Initiator Properties.

Add both iSCSI_1 and iSCSI_2 to it.

Move on to the Dynamic Discovery and add 10.0.1.3 as a new iSCSI Target.

Close the Window and Rescan the vmhba33 adapter.

Your 2 LUNs will become visible.  Note that we have 4 paths meaning 2 per LUN (= load balancing & failover possibilities).

Repeat the same procedure for ESXi2.

After that go to Configuration – Storage and create 2 new datastores on these LUNs.

Open the Properties of your Cluster and enable vSphere HA.

It should be enabled without errors (you will receive warnings if you don’t have Shared Storage, that’s why we enable it now and not during Cluster creation).

That’s it for now!  Next, we will create our vMotion interface!

Building the Ultimate vSphere Lab – Part 1: The Story

Building the Ultimate vSphere Lab – Part 2: The Hardware

Building the Ultimate vSphere Lab – Part 3: VMware Workstation 8

Building the Ultimate vSphere Lab – Part 4: Base Template

Building the Ultimate vSphere Lab – Part 5: Prepare the Template

Building the Ultimate vSphere Lab – Part 6: Domain Controller

Building the Ultimate vSphere Lab – Part 7: SQL Server

Building the Ultimate vSphere Lab – Part 8: vCenter

Building the Ultimate vSphere Lab – Part 9: ESXi

Building the Ultimate vSphere Lab – Part 10: Storage

Building the Ultimate vSphere Lab – Part 11: vMotion & Fault Tolerance

Building the Ultimate vSphere Lab – Part 12: Finalizing the Lab

Depending on the amount of memory you have, you can deploy as many ESXi hosts as you want.  Personally (I have 16 GB), i will install 2 of them.

Start by creating a new Virtual Machine.  Take Custom for the type of configuration.

Hardware Compatibility is Workstation 8.0.

Attach the ISO of VMware ESXi 5.0.  The wizard will detect ESXi automatically for you!

Call it ESXi1 and place it on HDD storage.  There is no use on putting it on SSD storage since ESXi has no real important data to store which is important from a performance point of view.

You can play around with the CPUs/Cores, but i give it a Dual Dual-Core (so cores in total).  Gives you some more cores to play with if you want to dive into the CPU scheduler details.

Give the ESXi host 4GB of memory.

Select Do not use a network connection as we will add it later on.

Accept the standard LSI Logic SCSI controller.

Create a new virtual disk and pick SCSI as the type.

Use a 40GB disk and store it in a Single File.

Complete the wizard and click Finish.

Edit the settings of you newly created VM.  Remove the Floppy and USB Controller.

Click Add and add a Network Adapter.  Attach it to the VMnet2 network.

Repeat the procedure and add a second Network Adapter to the VMnet2 network.  This will give you a screen like this:

Select the Processor item, and select Virtualizae Intel VT-x/EPT or AMD-V/RVI.  This allows you to run x64 guests on these ESXi hosts.

Now before starting and installing ESXi, take a Full Clone of this VM and name it ESXi2.  You can create a fresh VM as well, but cloning it will go faster.

Now, Power On you ESXi1 host.

The ESXi Installer will boot.

Follow the wizard and install ESXi on your 40GB local disk.

Use the same root password as you always do.

The installer will wipe your hard disk…  Let him do so by clicking F11.

After the installation, the host will reboot.  Press F2 to customize it.  You will need to login with root.

Select Configure Management Network.  First, go into Network Adapters and add vmnic1 to the list.

Give it IP 10.0.0.10/24 and set the default gateway to 10.0.0.1 (DC).

Get into DNS Configuration and set the DNS server (should already be set through DHCP but verify) and change the hostname to esxi1.labo.local.  Do not use capital letters here!

Exit the screens and enter Y to restart the Management Network.

That’s it for the basic ESXi installation… Quite easy eh?

Now repeat this part for ESXi2 (IP = 10.0.0.20).

After the two ESXi hosts have been installed, log on to the DC and open Server Manager – Roles – DNS Server – DNS – DC – Forward Lookup Zones – labo.local.  Create a A Record for both ESXi hosts.

Create a PTR Record as well!

You DNS should like like this:

Move over to the vCenter server.  You must be able to ping both machines using their FQDN now!

Open up vSphere Client.

First, create a new Datacenter and below it, create a new Cluster.

Turn on HA & DRS.

Leave all other settings to default and complete the wizard.

Now, add the two ESXi hosts to the cluster:

That will give this cluster layout in vSphere:

Both hosts will have errors (HA related, but it’s no big deal as we’ll solve them later on).

If you ESXi hosts disconnect continually, check Administration – vCenter Server Settings – Runtime Settings and fill in the IP of vCenter.

Building the Ultimate vSphere Lab – Part 1: The Story

Building the Ultimate vSphere Lab – Part 2: The Hardware

Building the Ultimate vSphere Lab – Part 3: VMware Workstation 8

Building the Ultimate vSphere Lab – Part 4: Base Template

Building the Ultimate vSphere Lab – Part 5: Prepare the Template

Building the Ultimate vSphere Lab – Part 6: Domain Controller

Building the Ultimate vSphere Lab – Part 7: SQL Server

Building the Ultimate vSphere Lab – Part 8: vCenter

Building the Ultimate vSphere Lab – Part 9: ESXi

Building the Ultimate vSphere Lab – Part 10: Storage

Building the Ultimate vSphere Lab – Part 11: vMotion & Fault Tolerance

Building the Ultimate vSphere Lab – Part 12: Finalizing the Lab

Create yet another linked clone based upon the Windows2008R2_Base VM and name it VC.  This must be stored on SSD as well.

The Virtual Network must be VMnet2.  Add it to the domain labo.local.

Create a user VCAdmin in AD and make this a member of the Local Administrators group on the VC.  Log on with that user.

First we need to install SQL Native Client.  This is located on the SQL ISO (the one you installed SQL Server on @ SQL VM).  It can be found in folder 1033_enu_lp\x64\setup\x64 and is called sqlncli.msi.

The installation is just a matter of Next, Next, Next, Finish

Now, hop on to the SQL VM and open SQL Management Studio.

Click Security – Logins – New Login.

The login name must be LABO\VCAdmin.

Right click Databases and select New Database.

Name it vCenter, set the owner to LABO\VCAdmin and size the MDF file to 100 MB.

On the Options tab, change the Recovery Model to Simple.

Get back into Security – Logins and open the properties of your LABO\VCAdmin account.  Go to the User Mapping tab.  Give the account do_owner permissions on both the msdb and the vCenter database! (the vCenter database should already be okay normally).

Okay, now head back to the VC VM.

Open up Administrative Tools and select Data Sources (ODBC).  Create a new System DSN.  Select SQL Server Native Client.

Name it vCenter and point to the SQL server.

Click Next on the following screen and…  uh oh

Go back to the SQL Server and open SQL Server Configuration Manager and Enable TCP/IP.  Restart the SQL Server Service.

After that, open Windows Firewall and select Allow a program or feature through Windows Firewall.  Click Allow another program.  Browse for it and go to E:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.

Go back to the VC and try again… it should proceed now.

Change the default database to vCenter.

Finish the wizard.

Now that we have the SQL stuff covered, it’s time to install vCenter!  Start autorun from the vCenter binaries.

Select vCenter Server (duh!)

Setup will complain that IIS is installed (got installed with the .NET installation routine).  Therefore, disable the World Wide Web Publishing service on the VC server.

The following screens are quite easy to understand.  Select use an existing supported database and select the vCenter ODBC source you created above.

It will detect that Windows Authentication will be used.  Fill in the password for the vCenter service (VCAdmin, the account we gave dbo permissions on the databases).  This will also mean that the vCenter service will be started with this VCAdmin account!

Accept the default installation paths.  Create a standalone VMware vCenter Server instance.

Set the JVM Inventory Size to Small.

Finally, click Install to start the installation.

To finalize, install vSphere Client.

Start vSphere Client, install the certificate and you should connect flawlessly to our brand new vCenter environment!

And in case you were wondering, all our 3 VMs together consume about 20 GB.  Not bad

That’s it for now!  Next up, we’ll start installing our ESXi hosts.

Building the Ultimate vSphere Lab – Part 1: The Story

Building the Ultimate vSphere Lab – Part 2: The Hardware

Building the Ultimate vSphere Lab – Part 3: VMware Workstation 8

Building the Ultimate vSphere Lab – Part 4: Base Template

Building the Ultimate vSphere Lab – Part 5: Prepare the Template

Building the Ultimate vSphere Lab – Part 6: Domain Controller

Building the Ultimate vSphere Lab – Part 7: SQL Server

Building the Ultimate vSphere Lab – Part 8: vCenter

Building the Ultimate vSphere Lab – Part 9: ESXi

Building the Ultimate vSphere Lab – Part 10: Storage

Building the Ultimate vSphere Lab – Part 11: vMotion & Fault Tolerance

Building the Ultimate vSphere Lab – Part 12: Finalizing the Lab

Again, store it on SSD storage.  Run through the OS Setup like you did with the Domain Controller.

Change the Network Adapter to VMnet2 to it can reach the DC.

If all goes well, you should get a DHCP address.

Give it a valid IP address and point the DNS Server to the DC.

Rename the Guest OS and make it a member of the labo.local domain.

Create a useraccount SQLAdmin in Active Directory (set the password to never expire).  Add this account to the Local Administrators group on the SQL VM.

Log on with this account to the SQL VM.

Before starting the installation of SQL Server, we’ll add an additional HD to the VM first.  We’ll throw all SQL binaries on that disk.

Right-click the SQL VM and select Settings.  Click the Add… button and pick Hard Disk.

Create a new virtual hard disk of 40 GB.  Store the virtual disk as a single file.

Rename the VMDK to something like SQL_Data.vmdk.  This makes it easier to locate the correct vmdk if ever needed.

Get back into the VM and format the disk.

In order to reach the SQL binaries (which are stored on the Windows 7 desktop VM), i use the Shared Folders feature of VMware Workstation.  This allows you to share a single folder between the hosts and the guest VMs.

Start the Setup of SQL Server 2008 R2.  Select Installation and pick New installation or add features to an existing installation.

I will run SQL in Evaluation mode, but if you have valid licenses, feel free to add them here

Some Setup Support Files will be installed.

You will get two warnings: one because you cannot access the Internet and a second because the Windows Firewall is enabled.

Select a SQL Server Feature Installation.

Install the Database Engine Services and the Management Tools – Basic.  Change the directories to you SQL Data drive (in my case E:)

Install a Default Instance but again, change the drive to the SQL Data drive.

Set the useraccounts for the services to LABO\SQLAdmin and change all services to Automatic.

Set the authentication to Windows and add the Current User to the SQL Administrators.

Finish setup.

That’s the basic setup for SQL Server.

Building the Ultimate vSphere Lab – Part 1: The Story

Building the Ultimate vSphere Lab – Part 2: The Hardware

Building the Ultimate vSphere Lab – Part 3: VMware Workstation 8

Building the Ultimate vSphere Lab – Part 4: Base Template

Building the Ultimate vSphere Lab – Part 5: Prepare the Template

Building the Ultimate vSphere Lab – Part 6: Domain Controller

Building the Ultimate vSphere Lab – Part 7: SQL Server

Building the Ultimate vSphere Lab – Part 8: vCenter

Building the Ultimate vSphere Lab – Part 9: ESXi

Building the Ultimate vSphere Lab – Part 10: Storage

Building the Ultimate vSphere Lab – Part 11: vMotion & Fault Tolerance

Building the Ultimate vSphere Lab – Part 12: Finalizing the Lab