Good question, it avgs just under 1.0 for the duration of the test. 

 

The odd thing is that writes remain 90+ MB/s... so that would imply the
network segments are configured correctly...

 

I also added a second iSCSI LUN and used the Win2K3 iSCSI initiator and
the performance is even MORE abysmal... so that would  SEEM to
eliminate the ESXi software iSCSI initiator from the equation...

 

It's gotta be on the SAN side.... Why on earth would reads be slower
than writes? Hmmm

 

-sc

 

 

 

From: Jeff Bunting [mailto:[email protected]] 
Sent: Wednesday, April 20, 2011 5:10 PM
To: NT System Admin Issues
Subject: Re: VMWare/iSCSI question

 

Does the latency to the disks/datastores look OK?  Can't think of much
else that you didn't already cover...

 

Jeff

On Wed, Apr 20, 2011 at 3:37 PM, Steven M. Caesare
<[email protected]> wrote:

Not an NT-specific question per se, but thought I'd float it out there,
as I've seen similar discussed:

 

So, I had ESXi 4.0 seeing ~93MB/sec on 1Gb links to my OpenFiler SAN.
Not bad , as that represents ~750Mbps before overhead on the link.

 

I upgraded my box to 4.1. Well, actually I re-installed v4.1, as I
decided to install to a USB flash drive, in order to eliminate spinning
media in the ESXi hosts themselves. After the new install, I imported
the existing machines that were originally living on the 4.0 build (they
were in a separate data store). I also installed additional NICS and
added more mem to the SAN.

 

My speeds dropped by about a  third to ~63MB/sec.  (Actually I got the
same ~90+ speeds ONCE, and then I decided to rebuild the RAID array as a
RAID0 stripe, rather than a RAID5, in order to see if I could completely
saturate the gig network links, it dropped after that)

 

Things I've tried:

 

1)      Updated the VMware tools in the guest OS's

2)      Double checking the iSCSI parameters in vSphere and OpenFiler

3)      Double checking my virtual nic/switch setup

4)      Confirming jumbo frames connectivity over the iSCSI network
path(i.e. ping -d -s 8000)

5)      Reverting back to the original NICS

6)      Removing the additional memory in the SAN

7)      Rebuilding the arrays back to their original RAID5 state

8)      Rebuilding the volumes/LUNs on the SAN

9)      Upgrading the Guest VM's from Virtual Machine v4 to v7

10)   Pulling out my hair

 

Things I haven't done, and why:

 

a)      Reverting back to ESXi 4.0u1 - This actually shouldn't be too
hard to do, as the drives with the existing ESXi build are still in the
server, just at a lower boot priority... I'd just have to pull the USB
key. The problem is I don't know how the guest OS's are going to behave
now that they are newer machine types (altho v7 is supported on ESXi
4.0u1 it seems), and have newer versions of VMWare tools installed on
them.

b)      Going back to spinning ESXi boot media rather than the USB flash
drive. All our new Dell servers  have the option to boot ESXi from
internal SD card, and it doesn't appear that the ESXi kernel really
needs high-performance _BOOT VOLUME_ storage once it's up and running.

 

Open to all suggestions

 

-sc

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

Reply via email to