VM /ETC

Archive for the ‘iSCSI’ Category

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 »

vSphere has introduced several new features for storage performance enhancement. Most of the new features build on already accepted vSwitch standards and designs. An important example is the new Round Robin MPIO path policy for VMFS LUNs. However, based on what is the common vSwitch design today, the new iSCSI configuration needed for Round Robin multi-pathing may cause some admins to look twice.

I was motivated to write this post by 2 recently published storage vendor documents that both recommend the same basic iSCSI vSwitch with Round Robin MPIO configuration: create a single iSCSI vSwitch, assign 2 physical NICs, and then create as many as 8 VMKernel Portgroups each with their own ip address. The documents I am referring to are:

• NetApp TR-3749 – NetApp and VMware vSphere Storage Best Practices http://media.netapp.com/documents/tr-3749.pdf
• Dell Equallogic CONFIGURING VMWARE VSPHERE SOFTWARE ISCSI WITH DELL EQUALLOGIC PS SERIES STORAGE – http://www.equallogic.com/resourcecenter/assetview.aspx?id=8453

To give a visual of the recommended configuration (in case you are still doing a double take) here are screen shots of the configured vSwitch from: Read the rest of this entry »

Surprisingly, Iomega can provide VMware certified low cost shared storage. I’ve heard mixed reports about actual performance, but none the less the filers provide cost effective options for VMware labs or small virtual environments.

The image to the right shows recent pricing on Amazon.com.

Fellow GestaltIT.com author and Microsoft Storage MVP Stephen Foskett has a great post with positive things to say on the Iomega models.

Iomega Grows Up and Moves Out of the House – Stephen Foskett

“…it was a surprise to find that the ix4-200r is certified compatible with ESX using both iSCSI and NFS right out of the gate. This is the only inexpensive storage system to wear a VMware badge, and this alone will likely make it a fixture in small offices and VMware labs. The desktop StorCenter ix4-100 and StorCenter ix2 are already widely used in these environments even without iSCSI, after all. The ix4-200r provides a complete SAN-in-a-box, supporting multiple NAS and iSCSI shares with dynamic allocation of the internal RAID-5 protected storage.”

Here is a screen shot from the on line VMware HCL showing the certified Iomega models.

Part of the magic hosting multiple virtual machines (VMs) on VMware ESX server is accomplished by leaning on the host’s CPUs to simultaneously handle networking loads. The more network I/O generated the more the CPUs have to work. When this happens the performance of the ESX host and the VMs can suffer because the result is limited access to available physical processing. Some common network I/O examples are software iSCSI adapter or NFS access to data stores, live migration of VMs between ESX servers via VMotion, and even administrator access with the VI Client.

Fortunately, ESX/ESXi 3.5 TCP Segmentation Offload, or TSO, can remove some of the networking burden from the host’s CPUs and improve overall performance. When the ESX server’s physical NICs support it, enabling TSO is as simple as choosing the right virtual network adapter, the Enhanced VMxnet adapter, for the VM. Surprisingly, making the Enhanced VMxnet adapter available to the VM is not a straightforward process because the Enhanced VMxnet adapter might not be an option in the virtual NIC properties or the Add New Hardware wizard.

First, you may be wondering how TSO reduces CPU overhead. 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 »

I received notice today about a project implementing ESX on IBM Blades and using System i for shared storage. After first doing a double take to make sure I read the email right, I did some quick research and found the following from the VMTN Communities:

VMware Communities: ESX on the IBM System i

“So how does VMware fit in with the System i? Well in a nut shell – The System i (which a lot of big companies have) can act as an iSCSI SAN, and you can boot IBM BladeServers and IBM System x Servers from this SAN, and have your shared storage too! Why is that so great? Because the IBM System i is one of the most reliable pieces of hardware on the planet! Because your company probably already has one! Because you can have a great backup and recovery platform!”

In case you are wondering what IBM System i is exactly, Read the rest of this entry »