EMC – VNX – Slow Disk Rebuild Times

I’ve been a bit behind on my VNX OE updates, and have only recently read docu59127_VNX-Operating-Environment-for-Block-,-EMC-Unisphere- covering VNX OE 5.33…102. Checking out the fixed problems, I noticed the following item.


The problem, you see, came to light some time ago when a few of our (and no doubt other) VNX2 customers started having disk failures on reasonably busy arrays. EMC have a KB on the topic on the support site – VNX2 slow disk rebuild speeds with high host I/O (000187088). To quote EMC “The code has been written so that the rebuild process is considered a lower priority than the Host IO. The rebuild of the new drive will take much longer if the workload from the hosts are high”. Which sort of makes sense, because host I/O is a pretty important thing. But, as a number of customers pointed out to EMC, there’s no point prioritising host I/O if you’re in jeopardy of having a data unavailable or data loss event because your private RAID groups have taken so long to complete.

Previously, the solution was to “[r]educe the amount of host I/O if possible to increase the speed of the drive rebuild”. Now, however, updated code comes to the rescue. So, if you’re running a VNX2, upgrade to the latest OE if you haven’t already.



VMware – Creating a 32bit DSN on a 64bit Windows machine (1010401)

I know I’ve covered this somewhere before – but this is just a reminder post for my own reference. When I was building my lab on vSphere 5.1 I had to configure a 32-bit DSN for VMware Update Manager- this link provides details on how to do it. I believe this is no longer necessary with 5.5. Again, not very exciting, but useful to know how to do it. Also, statements like “You can install the Update Manager server only on 64bit machines. However, Update Manager is a 32bit application and requires a 32bit DSN” still blow my mind.