VM /ETC

Posts Tagged ‘iSCSI’

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 »

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 »

A few virtualization bloggers have reported that they received an alert email from VMware about an I/O failure issue involving iSCSI or Fiber Channel (FC) SANs. There is also an alert currently dispalyed at http://www.vmware.com/support. In summary, an indefinite block occurs between ESXi/ESX 3.5 Update 3 hosts and VMFS 3 Luns which results in all paths to the storage entering a standby state. The issue is apparently isolated to the Update 3 version only.

Eric Sloof is one blogger that received the email and he has published his copy on his NTPro.nl blog. Here’s a brief quote from the email about the issue:

PROBLEM STATEMENT AND SYMPTONS:

• ESX or ESXi Host may get disconnected from Virtual Center
• All paths to the LUNs are in standby state
• Esxcfg-rescan might take a long tome to complete or never complete (hung)
• VMKernel logs show entries similar to the following:
• Queue for device vml.02001600006006016086741d00c6a0bc934902dd115241 49442035 has been blocked for 6399 seconds.
• Please refer to KB 1008130.

SOLUTION:

A reboot is required to clear this condition.

VMware is working on a patch to address this issue. The knowledge base article for this issue will be updated after the patch is available.

VMware KB 1008130 is titled VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely and provides the pattern of vmkernel messages that identify you have this issue:

Error messages matching this pattern are repeated continually in vmkernel:
<date and time> <hostname> vmkernel: <server uptime> cpu6:1177)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 7 seconds.
<date and time> <hostname> vmkernel: <server uptime> cpu7:1184)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 6399 seconds.

As stated in both the email and the KB article, unfortunately the only solution is to reboot your ESXi/ESX 3.5 Update 3 hosts until VMware is able to provide a patch.

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 »