Posts

Information

Beginning with the TS251R004 firmware release, the HP MSA VAAI plug-in is no longer supported as the HP MSA controller firmware now uses T10 compliance in an ESX Environment documented in TS251R004.

The HP P2000 G3 and the HP MSA 2040 are two widely used entry-level storage arrays. The P2000 G3 is VAAI capable since firmware version T230. But, contrary to the HP MSA 2040, you have to install the software plug-in for VMware VAAI if you use the P2000 G3. According to the “HP MSA 2040 Storage Configuration and Best Practices for VMware vSphere” whitepaper the MSA 2040 supports VAAI nativly without an additional plugin.

Today I was onsite at a customer to bring a tiny VMware vSphere cluster to life (HP BladeSystem c7000 with 7 HP ProLiant BL460 Gen8). Normally no big deal, but it started with two unavailable Onboard Administrator (OA) network interfaces. I switched from static ip addresses to DHCP, but I had no luck. I noticed that both interfaces were available if I connect my notebook directly to the interfaces. I even noticed that the Insight Display was unresponsive after connecting one or both OA to the network. The customer told me, that they had yesterday network related problems with virtual AND physical machines. Short outages, lost pings, things like that. This morning, before I arrived on site, the problems were worse. The customer told me that they had this network problems for a while. They had a lot of work and the outages were annoying, but not a big problem. The network of the BladeSystem were already connected (HP 10GbE Pass-Thru modules), but this kind of interconnect couldn’t cause this kind of problems. I checked the Switches and found on EVERY SINGLE ACTIVE port an enormous amount of “Drops TX”. But I found no loops or something like that. The network was flat. One VLAN and a /16 network. Not nice, but functional. I asked the customer to start Wireshark. I wanted to take a look around, get a feeling for what was going on in the network. Wireshark started and… stopped responding. After a couple of seconds it came back and I saw traffic that was… spooky. Usually I expect things like broadcasts, ARP, traffic from my client or for my client. But I saw traffic from a domain controller to a Windows NLB cluster and Citrix traffic to a Windows NLB cluster. I checked if the workstation was connected to a monitoring port, but it wasn’t. And it was only traffic with destination to the Windows NLB cluster. Our network problems had something to do with the Windows NLB. The customer and I decided to stop both NLB nodes. After that: Silence… I saw the expected traffic in Wireshark and my OA were both responding. Everything was fine… until we started the NLB again.

Yesterday I got an e-mail from DataCore in which Update 2 for DataCore SANsymphony-V PSP4 was announced. DataCore found a critical issue in all releases since SANsymphony-V 9.0 PSP3. According to the releases notes a situation can occur, in which storage space reclamation and migration can happen at the same time. This can lead to a situation in which two storage allocation unit (SAU) can point to the same disk offset. If this happens, the disk pool can be marked offline.

In part I and part II of this series I showed how to install the WDS role, MDT 2013 and ADK for Windows 8.1. I showed the process to import the OS images and the necessary drivers for our deployment. Now it’s time to bring MDT to life. Let’s start with part III of this series.

After installing the required software, we need to configure MDT 2013. You need:

• Windows Server 2008 R2 ISO
• VMware Tools for Windows ISO or a Server with VMware Tools installed

The deployment share

First of all we have to create a deployment share. This file share is used to access the software, drivers etc. during the deployment phase. Just start the Deployment Workbench, that can be found in the start menu. Right click the menu item “Deployment Shares” and click “New Deployment Share”.

Usually you can install virtual servers on four different ways:

• Installation from scratch
• image-based installations (e.g. Clonezilla)
• VMware templates and template customization specifications
• automated deployment

Except VMware templates you can use every technique to deploy physical and virtual servers. I would like to show you how you can install windows-based VMs with Microsofts Deployment Toolkit 2013 (MDT 2013). There are three articles in this series. The first article describes what you need for MDT 2013 and how you install WDS. The second article will show you how to configure MDT 2013, import the necessary drivers and OS images. The third article describes how to deploy a Windows 2008 R2 server with VMware Tools.

What are the requirements of MDT 2013?

The requirements are manageable. To recreate my small lab environment, you need two VMs or physical servers and a evaluation copy of Windows 2008 R2. MDT 2013 and ADK for Windows 8.1 can be downloaded for free on microsoft.com. I used two Windows 2008 R2 VMs for my setup. One VM as a Domain Controller with DHCP and the second VM for MDT 2013 and WDS.

During the installation of a really small vSphere environment, I used the 60 days instand-on license. This allows me to use some fancy vSphere Enterprise Plus feature during the installation. Specifically I use host profiles to configure the ESXi hosts. At the end of the installation process I removed the host profiles and installed the Essentials Plus license. The enviroment consisted of two HP ProLiant DL360 Gen8, a dual-fabric SAN with a HP MSA 2040, two Brocade 300 FC switches, some more stuff and a vSphere Essentials Plus license. The customer and I decided to install VMware vCenter 5.5.0b and ESXi 5.5.

While playing around in my lab, I wanted to enable VMware Fault Tolerance (FT)  for a VM. In the absence of physical HW I use a nested enviroment, which is running on a HP ProLiant DL160 G6 (2x Intel Xeon E5520, 32G RAM, a RAID 0 with 4 SATA drives). FT isn’t available in nested enviroments, because HW virtualization features are required. This screenshot was taken from the web client.

During a vSphere 5.0 > 5.5 upgrade I got this message:

The SSL certificate for this product is expired. See Knowledge Base article kb.vmware.com/kb/1009092

The customer hasn’t installed CA-signed certificats, so the expired certificates are the out-of-the-box self-signed certificates. The certificates are valid for two (VirtualCenter 2.5) respectively 10 years (since vCenter 4.x), depending on the Version. The only way to continue the installation is to renew the certificates. After renewing the certificates, you can simply continue the setup due the fact, that the vCenter service is stopped at this point of the setup and it loads the new certificates during startup. It’s the setup which checks the validity of the certificates. KB1009092 describes in great detail what to do, so I will not repeat what is already written there. You should note, that you can’t use the ESXi busybox to renew the certificates. The necessary OpenSSL binary isn’t included. The KB articles recommends OpenSSL for Windows. I simply used my Linux root server. But you can also use a small Linux VM. After renewing the certificates for vCenter, Inventory server and Web Client I simply continued the setup and it ran without problems by. The deployment of CA-signed certifcates is planned.