VM /ETC

Archive for the ‘SAN’ Category

This is just a quick note that the previous issue with vSphere customers using NFS storage and CBT has been resolved with a recent patch. More on the previuous problem and the new patch in this KB article:

http://kb.vmware.com/kb/1031106

The KB was updated 7.26.11

Surely you’ve heard about Drobo by now? As the presenter in the last slot of the GetsaltIT Tech Field Day (TFD) schedule a few weeks ago,  Data Robotics was probably the most anticipated session by my fellow Delegates. I’ll admit, I had heard enough about the technology during the 2 day event that I was looking forward to the presentation as well. Data Robotics did not disappoint. Evidence can be seen in the enthusiasm expressed in the various posts and videos published since that session.

As always, I’ll leave the deep technical details of Drobo’s unique and patented Drobo BeyondRaid technology to my fellow storage bloggers and stay focused on how Data Robotics fits in virtual infrastructure. In this post I expand a little on why the Drobo storage device is a VMware HCL certified, simple to implement and expand iSCSI SAN targeted for SMB customers that is an exciting alternative. Finally I offer opinions based primarily on my virtualization server administrator perspective.
Read the rest of this entry »

Most physical to virtual migrations (P2V) of servers end up as virtual machines with the partitions encapsulated in virtual disk (.vmdk or .vhd) files. But what if the physical server already has a partition that’s configured through an iSCSI connection to the SAN, and what if that’s the same SAN that the new VM will run on? Of course, the new VM will have to be on a different LUN (formatted for use by the virtualization host), but should you encapsulate the current NTFS iSCSI partition or should you maintain the iSCSI initiator within the resulting VM? The former option depends on how much available SAN space you have to work with, the latter requires some extra thinking before you begin.

When you decide to maintain a server’s existing iSCSI partitions as a VM, there are several configuration considerations to plan for.
Read the rest of this entry »

iSCSI – Hardware or Software – How many TOEs do you have? is a post by Carlo Costanzo that really struck a chord with me. Carlo asks:

“More and more of my new implementations of VMware Infrastructure are being connected to iSCSI SANs (EMC, LeftHand, and Equallogic) and the question has come up about whether or not to spend extra dollars on TOE (TCPIP Offload Engine) Network cards.”

This made me realize that I have yet to implement an iSCSI SAN connection to an ESX Cluster with a hardware initiator. My customers have all used the native ESX iSCSI software initiator instead. So it made me wonder why am I not even considering the hardware iniator anymore, and should I present the option to my customers at all? Afterall, as Carlo points out, the number of supported TOE cards has increased from 2 to 16 (a table is provided at the end of this post)

I came up with a short list of reasons why I haven’t been using the iSCSI hardware initiators. Read the rest of this entry »

If you are considering virtualizing SQL, check out a great post from vm0.blogspot.com. Running SQL Server on ESX makes some great suggestions for planning  CPU, RAM, and Disk I/O to allow for the highest performance possible of your database virtual machines (VM).

The section on disk I/O made me think – specifically about whether creating RDMs to raw disks was really a better choice than carefully planning VMFS LUNs. There is just too much convenience with using VMFS in my opinion, and I’ve never really been convinced that any report or testing has proven RDMs offer better performance than carefully planned VMFS. So, instead of a long comment on the vm0 post I decided to blog about it here at VM /ETC.

Be sure to read the entire post for the RAM and CPU recommendations, but here is the section that inspired me: Read the rest of this entry »

For my project, 5 TB of raw disk space on a NetApp FAS3020 resulted in roughly 2.5 TB of usable NFS volumes. Sacrificing half the storage as overhead (for both ESX and NetApp) might seem like a big hit to take at first, but when you consider what you are able to do in the remaining useable space it can change your opinion. In my recent experience, after combining the features of Flexclones, VirtualCenter (VC) templates, deduplication, and NFS the remaining 2.5 TB enabled a virtual desktop infrastructure (VDI) storage solution for over 80 virtual machines (VMs). Your results may vary, but the concepts discussed in this post provide for a scalable and flexible design.

Although this post discusses NetApp, I imagine any NFS filer with similar features could be used in this same fashion. I’m curious for feedback on not only this solution, but the pros and cons of other vendor’s features in a similar scenario.

Here’s a logical diagram illustrating a NFS volume strategy followed by some high level details of each volume. Read the rest of this entry »

The problem surfaced from a ESX 3.5 U2 host fiber connected (FC) to a NetApp filer. An AutoSupport email was generated (NetApp’s filer “phone home” feature) with the following information:

This AutoSupport indicates that there is a configuration issue in the FCP partner path.

Information:
============

[hostname: scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured.
[hostname: scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured – Host I/O access through a non-primary and non-optimal path was detected.

The AutoSupport email even explained what causes the misconfigured path.

This message occurs when the system detects that host I/O access to logical units (LUNs) is not through a primary path. NetApp clustered storage controllers allow access to LUNs through primary, optimized paths, and secondary, non-optimized paths.  Secondary(non-primary) paths provide access to LUNs through the partner storage controller’s FCP target ports. Under normal operating conditions, a host should not perform I/O to LUNs using a non-primary path. Access through a non-primary path should only occur when a host’s MPIO software detects a failure of all primary paths.

The mystery for me was “what caused a failure of the primary path?“. Believe it or not, Read the rest of this entry »