© sfoskett for Stephen Foskett, Pack Rat, 2010. | How Fast Is It? A Storage Infographic
This post was categorized as Apple, Computer History, Enterprise storage, Features, Personal, Terabyte home. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

The Four Horsemen of Storage System Performance: These four ugly gentlemen stand between you and your data.

Why do some data storage solutions perform better than others? What tradeoffs are made for economy and how do they affect the system as a whole? These questions can be puzzling, but there are core truths that are difficult to avoid. Mechanical disk drives can only move a certain amount of data. RAM caching can improve performance, but only until it runs out. I/O channels can be overwhelmed with data. And above all, a system must be smart to maximize the potential of these components. These are the four horsemen of storage system performance, and they cannot be denied.

The Chain of Command

It is tempting to think of storage as a game of hard disk drives, and consider only The Rule of Spindles. But RAM cache can compensate for the mechanical limitations of hard disk drives, and Moore’s Law continues to allow for ever-greater RAM-based storage, including cache, DRAM, and flash. But storage does not exist in a vacuum. All that data must go somewhere, and this is the job of the I/O channel.

To be useful, storage capacity must connect to some sort of endpoint. This could be the CPU in a personal computer or an embedded processor in an industrial device. Indeed, there are endpoints and I/O channels throughout modern systems, with potential bottlenecks, caches, and smarts at each point. “Storage people” like me tend to think too small – imagining that the I/O channel ends at the disk drive, the “front end” of the array, or the storage network. But data must travel further, all the way to its final useful point in the core of the CPU.

Once we consider I/O as a long chain of interconnected endpoints, we begin to see the fact that I/O constraints at any point can strangle overall system performance. This is not merely an academic exercise: Optimizing the I/O channel is a consuming passion for most practitioners of enterprise IT, including architects, engineers, and system developers. And, like a good game of Whack-a-Mole, increasing the speed of one link causes another chokepoint to rear its head.

Parallel and Serial I/O

Imagine you had a warehouse full of boxes to move across the country as fast as possible. There are a few options available to you:

1. A fast truck can zip back and forth with just a few boxes
2. A train is slower, but its many cars can haul a huge quantity

But there are realistic limits to both capacity and speed: The train has to fit on the tracks, and the truck can’t move at the speed of light. Plus, one must consider the time taken to load and unload the chosen vehicle.

We continually shift between parallel and serial I/O paradigms

The same trade-offs are true of computer busses: Serial channels can be optimized to zip individual bits back and forth, or parallel busses can be designed to carry whole bytes (or more) at a time. The simplicity of serial communications is tempting, but designers continue to resort to parallelization for added throughput.

Note: Most serial protocols actually feature two links, making them “full duplex”: One for transmit and another for receive.

Serial storage interconnects are dominant currently, with fraternal twins SAS and SATA coming to dominate the disk interface landscape. SAS and SATA share the same 1.5, 3, and now 6 gigabit per second serial physical interconnect, offering more than enough throughput for conventional hard disk drives and edging out older serial (Fibre Channel, SSA) and parallel (ATA and SCSI) alternatives.

Networks (Ethernet, Fibre Channel, and InfiniBand) are predominately serial as well, as are lower-end interconnects like USB and FireWire. Serial communication also dominates in the system bus world, with serial PCI Express toppling parallel PCI.

But parallel variants are often offered for increased throughput: Multi-lane PCI Express and bonded multi-link InfiniBand make up a fair portion of the installed base, while load balancing MPIO drivers are common in Fibre Channel storage. And let’s not forget that the “X4″ variants of Ethernet use multiple bonded links as well.

The Definition of Bottle Neck

Most English speakers have encountered the French term, “cul de sac”, meaning “bottom of the bag” or dead end. But hard disk drives have plenty of “bottom end”, or storage capacity. When it comes to disks, the issue is usually at the neck of the bag: Data just can’t be pulled out of a hard disk drive fast enough.

Emptying a barrel of wine through a spigot takes hours, but pry the end off and the floor is covered in a moment!

The density of modern hard disk drives (the capacity of our barrel) has been growing much more rapidly than the I/O channels serving them (the spigot). Where once a hard disk drive could be filled or emptied in an hour or two, modern drives take days or weeks!

I once called this “flush time“, but I think the wine metaphor is much more appetizing!

This “bottle neck” has serious implications beyond basic storage performance. Data protection is impacted, since ever-larger storage systems can no longer be backed up by dumping their content; system reliability is reduced, since week-long RAID rebuilds increase the risk of multiple drive failures; and cost containment efforts are also impacted, since adding spindles drives up prices.

Nowhere is this bottleneck more evident than in portable devices. Modern drives (like the 1 TB Seagate USB drive I recently reviewed) have massive capacity and pathetic performance. The USB 2.0 interface just can’t keep up, and this creates a limit to the expansion of capacity. It would take half a day to fill that drive under perfect conditions at 25 MB/s, reducing its value as a massive data movement peripheral. The emerging USB 3.0 standard promises to alleviate this performance issue for now, as illustrated with Iomega’s new external SSD.

Cache and solid state storage can help, but they have their own bottlenecks. Storage arrays typically use Fibre Channel or SAS SSDs, and their front-end interface remains the same. The best-performing SSDs use the PCI Express bus directly rather than emulating hard disk drives over SCSI interfaces. And even PCI Express might not be enough to handle the massive I/O of NAND flash or DRAM. In each case, the bottleneck moves down the chain.

A Chain of Bottlenecks

Let’s follow a typical I/O operation from the disk to the CPU core and count the I/O channels:

1. A read head senses the state of a bit of magnetic material on the surface of a disk
2. The head transmits this signal to a buffer on the disk controller board
3. The data is picked up by the disk controller CPU and transmitted over a SATA or SAS connection
4. The storage array or RAID controller receives the data and moves it over an internal bus to another buffer or cache
5. The data is picked up by another CPU in the array controller and sent out another interface using Fibre Channel or Ethernet
6. The data is buffered and retransmitted by one or more switches in the storage network
7. The host bus adapter (HBA) on the server side receives the data and buffers it again before sending it over a local PCI Express bus to system memory
8. The server memory controller pulls the data out of system memory and sends it via a local bus to the CPU core

There are actually many more steps than this, but the picture should be clear by now. There are many, many I/O channels to consider when it comes to storage, and the drive interface is just one potential bottleneck.

We constantly move bottlenecks around - as one link is improved, another choke-point appears

Optimizing Storage I/O

Tactical steps to improve storage performance typically focus at one link in the chain: Drive vendors move from 1.5 Gb to 3 Gb SATA, or SAN buyers upgrade from 4 Gb to 8 Gb Fibre Channel. But the basic architecture of enterprise storage has remained constant for over a decade, and the reliance on block SCSI commands endures. This is all about to change.

One critical bit of I/O optimization exists at the point of connection between the various chipsets inside the server. AMD pulled the memory controller off of the “northbridge” with their Athlon line. Intel did the same with their Nehalem and is eliminating the northbridge entirely with the Lynnfield/Jasper Forest CPU lines. This gives serious bandwidth to the crucial PCI Express-to-CPU-core link, moving the bottleneck downstream.

We are in the midst of a massive upgrade of the storage network as well. Between 8 Gb Fibre Channel and iSCSI and Fibre Channel over 10 Gb Ethernet, not to mention persistent interest in InfiniBand, storage network throughput is rapidly expanding. As with the internal PC connections, the expansion of network bandwidth has pushed the bottleneck to the storage array interface for the time being.

Microsoft and Intel recently pushed over a gigabyte per second over 10 GbE using iSCSI, but they needed multiple storage targets to feed that connection. It isn’t that modern storage systems couldn’t push that kind of I/O (indeed, arrays are tens to hundreds of times faster internally thanks to their spindles and cache), but that the conventional storage protocols are tightly linked to a single “front-end” interface. The current state of the art for storage array design is moving to distributed models, exemplified by pNFS and scale-out NAS concepts like MaxiScale (now acquired by Overland).

Once the array interfaces can pump out massive I/O, attention will turn once again to the disk interfaces themselves. Although 6 Gb/s SAS and SATA is now a reality, this interface is inappropriate for future high-performance SSDs. Arrays designed around flash or DRAM are likely to switch to PCI Express as their internal connection of choice for performance and to optimize data placement on these new devices. Companies like Nimbus and NetApp are already moving in this direction.

Time To Get Smart

Hard disk drive spindles make up the bulk of storage capacity, but small amounts of cache make them far more effective. But both of these horsemen must operate within the constraints of the I/O channels they pass through. This brings us to the final horseman of performance: Smarts. Clever designers have created clever controlling mechanisms to overcome the limits of spindles, cache, and I/O channels.

© sfoskett for Stephen Foskett, Pack Rat, 2010. | The Four Horsemen of Storage System Performance: I/O As a Chain of Bottlenecks
This post was categorized as Computer History, Enterprise storage, Personal, Terabyte home, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

STEC has introduced ZeusRAM, a SDRAM-based drive

The ZeusRAM is small (just 8 GB) but STEC claims massive performance: 80,000 IOPS for both read and write (versus 80,000 read and 45,000 write for the 6 Gb SAS ZeusIOPS) and 500 MB/s sustained read and write (versus 350 and 300 for the ZeusIOPS). These numbers are well beyond the capabilities of whole shelves of traditional hard disk drives.

Should it lose power, the ZeusRAM will de-stage its content to flash RAM using power stored on internal super-capacitors. This is a major differentiator from in-system RAM disks which require whole-system battery backup and software to de-stage.

STEC has not announced pricing or availability information for the ZeusRAM drive at this point. We noted much interest in the drive from EMC staff at the EMC World show, and would not be surprised to see the ZeusRAM show up in a future Symmetrix or CLARiiON.

© sfoskett for Stephen Foskett, Pack Rat, 2010. | STEC Spills the Beans on ZeusRAM SSD
This post was categorized as Enterprise storage, Gestalt IT. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

For more information on earlier updates, see my articles:

• Storage Fixes in VMware ESX Server 3.5 Update 2
• Storage Changes in VMware ESX 3.5 Update 3

Expanded Support for Enhanced vmxnet Adapter

Not specifically a storage change, but the enhanced vmxnet adapter introduced back in the original release of ESX 3.5 now works with most versions of Windows Server 2003 and XP Pro. Look for improved performance when using guest-side SMB and NFS as well as the guest iSCSI initiator. Note that you cannot select this driver when configuring non-Enterprise Edition machines; you have to select Windows Server 2003 Enterprise Edition (64-bit) regardless of which version of Server 2003 you are using.

Expanded SAS and SATA Controller Support

If you’d like to install ESX on a server equipped with a PMC 8011, Intel ICH9 or ICH10, CERC 6/I SATA/SAS Integrated RAID Controller, or HP Smart Array P700m Controller, you’ll find happiness in Update 4.

The Intel controllers are especially important, as we’re seeing them used more and more and this driver is more full-featured than the earlier Broadcom HT 1000 and Intel ICH7 drivers. The Intel ICH9/ICH10 is a dual-mode (IDE/ATA and AHCI/SATA) driver, supports SATA hard drives, SSDs, and optical drives, and now enables VMFS support when in AHCI/SATA mode. It’s not clear whether VMware actually supports VMFS datastores on ICH9/10 SATA, but it says it works. Anyone want to try it out? One thing is certain: You can’t use SATA drives in a shared/clustered environment because SATA does not include reservations. See this tech note and especially this question:

Earlier, it was mentioned that we can create VMFS if we use AHCI/SATA mode. If so, why did VMware not claim VMFS support when using SATA controller running in AHCI/SATA mode?

VMware might decide to add support in the near future. There is no strong need to have VMFS support on a SATA drive, because native SATA protocol does not support reserve/release. Reserve/release is needed if VMFS is used as clustered file system in a shared disk environment.

PXE Boot Support

Rich at VM/ETC points out that Update 4 includes experimental PXE boot support for ESX and ESXi. As he notes, this has major implications for cloud computing platforms, since it means that ESX servers can boot guests without local storage at all. Very interesting! Let’s bet that Update 5 (expected in June or July) will include this as a supported option.

Updated QLogic, Emulex, and LSI Drivers

Like most ESX updates, this one included updated Fibre Channel drivers.

• The QLogic Fibre Channel Adapter driver and firmware (versions 7.08-vm66 and 4.04.06, respectively) include bug fixes and enhanced NPIV support.
• On the Emulex side, driver version 7.4.0.40 supports the company’s HBAnyware 4.0 management software.
• Users of SAS and SCSI LSI MegaRAIDs will find driver version 3.19vmw (megaraid_sas) and 2.6.48.18 vmw (mptscsi) which improves performance and enhances event handling capabilities.

Expanded Sun Storage Array Support

All you StorageTek loyalists out there will be happy to see support for Sun’s low-end StorageTek 2530 SAS array as well as the modular 6580 and 6780 Fibre Channel arrays. It looks like just about every model in Sun’s current storage lineup is now supported in ESX.

Expanded Network Card Support

Support for Gigabit cards is greatly expanded, including HP’s quad-port NC375i and dual-port NC362i and NC360m, Intel’s Gigabit CT and 82574L, and NetXtreme’s BCM5722, BCM5755, BCM5755M, and BCM5756. Intel’s widely-used 10-gig 82598EB cards are now supported as well.

Tweaks and Fixes

Looking through the release notes, a few storage-related tweaks and fixes stand out:

1. WMware can optionally automatically throttle back the queue depth when congestion is encountered. See Controlling LUN queue depth throttling in VMware ESX for 3PAR Storage Arrays for more information.
2. VMklinux module heap size can now be adjusted as LUN queue-depth values are increased. Since tuning LUN queue depths is one common trick of the storage trade to improve performance, especially in queue-stingy systems like ESX, this is welcome news. But call VMware support before you monkey with it!
3. An RDM-related issue where SCSI inquiry data over 36 bytes was truncated or corrupted (for example when using Microsoft VSS and NetApp SnapDrive) has been resolved.

Well, that’s all folks. I suggest you all read the release notes for yourself, and please leave a comment if you see an error in what I wrote here or have something to add!

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Storage Changes in VMware ESX 3.5 Update 4
This post was categorized as Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

But when will 10 Gb and FCoE arrive? Dave Raffo and I discussed the topic after Storage Decisions, and he just wrote an article on the topic, 10GigE still seeking killer app. Here are some points that came up in our discussion:

• Shipping and supported 10 Gb HBAs and CNAs are the key requirement, and it looks like the schedules of Microsoft, VMware, Sun, and Linus Torvalds will determine when the floodgates open
• iSCSI people are talking 10 Gb, too, and they might end up adopting it first with software initiators
• Interest in FCoE is focused at the largest enterprise shops, and I’m seeing a distinct line between “iSCSI shops” and “(future) FCoE shops” with very little overlap (as I previously noted, iSCSI and FCoE aren’t mortal enemies, and FCoE will rule in the largest environments)
• No one is talking about 8 Gb Fibre Channel – they have all decided that 10 Gb FCoE or iSCSI is the next step for block storage
• InfiniBand has its believers (and they are rabid fans!), but the users I talk to are, as a rule, heading toward FCoE rather than IB for their future connectivity
• There is a tiny bit of user interest in moving back to SAS-enabled DAS for virtual server environments
• Everyone I talk to is shocked there isn’t a 10 Gb iSCSI array on the market yet, and we all expect to see this before FCoE
• Although some vendors have announced FCoE products, they’re not here yet – and it will be another year still before we see production deployment

See my posts on Gestalt IT for similar enterprise IT infrastructure commentary

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Storage Folks Are Talking 10-Gig and FCoE
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

For more information on Update 2, see my article, Storage Fixes in VMware ESX Server 3.5 Update 2.

Update 3 is not as important from a storage perspective, but there are some goodies in there:

• New VMDK recovery tool (nifty!)
• Storage tweaks like fixed multipathing on IBM SVC, interrupt coalescing on QLogic 4 Gb FC HBAs, and some bug fixes
• Expanded support for SATA (but not for VMFS), SAS, and some Broadcom NICs (but still no TOE)

Read on for more details!

VMDK Recovery Tool

ESX users with Update 3 get a nifty new script for deeper inspection of disk image files on VMFS. Although I haven’t had a chance to try it out yet, it appears to be related to VCB, in that it identifies which disk blocks make up a VMDK. But the VMDK Recovery script (which runs in Service Console on ESX – sorry, ESXi!) allows you to copy these blocks to a new file.

What good is this? Well, it could certainly be used to recover VMDK files from corrupted VMFS datastores, and could serve as an undelete feature as well. And as Rich Brambley points out on VM/ETC, it could be the basis for some nifty scripted backup and restore operations as well. I’m looking forward to seeing what happens with this, but it’s definitely a minor addition.

Storage Tweaks

Update 3 includes some minor tweaks and bug fixes in storage:

• ESX used to only support most-recently used (MRU) multipathing with IBM’s SAN Volume Controller storage virtualization platform, but Update 3 allows fixed policies to be used as well.
• The VMkernel iSCSI driver gets two new advanced configuration options (Disk.UseLunReset and Disk.UseDeviceReset) to control whether multipath failover will issue a LUN reset or target reset.
• SCSI sense codes are now included in /var/log/vmkernel by default.  This should assist in deep troubleshooting of storage problems.
• The lengthy iSCSI target discovery process that used to happen whenever a discovery address was added has been removed, speeding up iSCSI storage configuration.
• Users of QLogic 4 Gb Fibre Channel HBAs will now get updated firmware and a new performance feature called interrupt coalescing. As it sounds, IC will combine interrupts from multiple I/Os, improving overall performance by reducing the number of interrupts the CPU has to handle.

Note that VMware ESX 3.5 Update 3 still doesn’t really make maximal use of 10 Gb Ethernet. Besides the lack of TCP offload engine (TOE) support, the company still doesn’t make any speed claims when people step up to faster NICs. The Known Issues list specifically says it’s for connectivity, not performance. At least the QLogic iSCSI HBA support is pretty good.

[ad#banner]

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Storage Changes in VMware ESX 3.5 Update 3
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

This is part of an ongoing series of longer articles I will be posting every Sunday as part of an experiment in offering more in-depth content.

There has been a lot of discussion in the storage industry about Fibre Channel over Ethernet (FCoE), making it the toast of Storage Networking World, but this technology remains relatively unknown to end users. Like so many storage protocols before it, the $10,000 question is whether FCoE will take off like iSCSI or fizzle as a niche product like FCIP, DAFS, and so many others.

If it does succeed, another critical question is what this means for iSCSI, Fibre Channel, InfiniBand, and to a lesser extent AoE, expanded SAS, and other options for SAN storage. The enterprise data center is poised for a complete change in server connectivity, with 10 Gb Ethernet converged network adapters (CNAs) and new core switches carrying both network and storage traffic, and this holds promise, especially in virtualized environments. But CNAs do not equal FCoE, and iSCSI, conventional Fibre Channel, and other protocols are roaring ahead. What impact will FCoE really have?

Why FCoE Matters

With 8 Gb Fibre Channel and alternative storage solutions leveraging InfiniBand now available (and with 10 Gb iSCSI imminent), many would ask why we need another enterprise block storage medium. In real-world applications, FCoE at 10 Gb will likely deliver roughly the same performance as 8 Gb native FC. But FCoE will be one or two years late and (initially) more expensive. Although active standards participation and “plug fests” mean FCoE will likely be more interoperable than Fibre Channel was in its early years, the lack of support from operating system manufacturers is troubling. Plus, users will soon be able to build a very similar infrastructure by mixing iSCSI and 10 Gb Ethernet, and this will include all the advantages of IP and solid support.

So why pay more for the same performance from an untested protocol? It’s all about the future, and enterprise users will go where the market goes, just as wide availability of VHS tapes buried Betamax. Storage, network, and SAN vendors alike are lining up solidly behind FCoE as the next-generation enterprise interconnect. Although InfiniBand plays Betamax in this home video metaphor, with superior technology and availability, FCoE’s VHS camp has all the market ammunition. To paraphrase the (alleged) words of Bob Metcalfe, no matter what the technology looks like, the future of networking will be called Ethernet.

The biggest storage vendors are behind FCoE simply because they see that converging and leveraging I/O technology makes sense for them. They can swap out the physical and data link layers from Fibre Channel to Ethernet relatively easily, so the FCoE switch is an easier change than iSCSI. It is likely that they will be able to leverage commodity Ethernet hardware to reduce (their, not your) cost and increase profit margins once this switch is made. Plus, FCoE will potentially increase SAN attachment rates (and thus enterprise storage market penetration) thanks to the potential availability of converged network adapters (CNAs) on the server side, and the cost-effectiveness that sharing a CNA between network and storage implies. From the storage side, FCoE is all good.

Also see my posts on FCoE versus iSCSI and Cisco VFrame

The drive is similar on the network side. The era of differentiated SAN and LAN producers is over – all of the major networking and SAN vendors are repositioning themselves as next-generation I/O providers, setting up a battle in the network space to rival the mainframe shakeout of the 1980s and the PC wars of the 1990s. Converged I/O is the business model for connectivity vendors, and most are taking up the “data center Ethernet” (DCE) charge (also called “converged enhanced or enterprise Ethernet” or CEE) which includes FCoE as the storage protocol for virtual I/O. iSCSI is still there in a DCE world, but FCoE will take center stage for the enterprise market.

Counting the Benefits of FCoE

It may seem strange to declare an upstart like FCoE the winner when established options like InfiniBand, conventional Fibre Channel, and iSCSI are already out in the market, but this examination of the vendors indicates that it is indeed the case. Is this a case of the tail (vendors) wagging the dog (consumers)? Perhaps, but they will come along willingly given the strong case presented by converged and virtualized I/O.

Enterprise buyers are ready for a next-generation SAN technology, and some are beginning to look at 8 Gb Fibre Channel. The few that really need performance will certainly buy 8 Gb FC today, but this has little bearing on the overall prospect for FCoE. When an application requires performance and money is available, purchases will be made regardless of future strategy.

Enterprise storage and network architects are beginning to consider the implications of server consolidation and virtualization. As they see footprint shrink thanks to compact or blade servers and server virtualization, they will begin to question the proliferation of interconnects on the back end required to keep up with the I/O demands of these super servers. Already, virtual I/O purveyors like Xsigo are making hay in this market, and, as mentioned above, their SAN and LAN vendors are spreading the message, too. It won’t be long before they are convinced.

Also see my posts on VMware VDC-OS and VDC-OS vStorage

Many people mistakenly assume that DCE means pushing all protocols through a single LAN, but this is not the case. These networks will be engineered like SANs from the start, with redundant connections and transparent failover. Although storage and network connectivity will share the same physical “pipe”, they will certainly be segregated on separate VLANs and protected with quality of service technologies. They have to be separated – FCoE (lacking IP) will require a totally different network topology than LAN connections.

So Who Buys FCoE?

Note that, throughout this discussion, I am referring only to the large-scale enterprise data center storage market. Smaller corporate environments have already embraced iSCSI en masse, expanding the penetration of consolidated storage concepts beyond anything Fibre Channel could ever accomplish. And small office and home networks are beginning to embrace these concepts as well, but are relying on protocols like CIFS and AFP for file servers and may begin to look at ATA over Ethernet (AoE) and proprietary protocols like the one pushed by Zetera/NetGear instead of iSCSI.

This leaves us with a layer cake of appropriate protocols from the smallest to largest networks. But all have one thing in common: They are all converged and they are all carried in Ethernet packets. Bob Metcalfe was right!

Update: Storagebod points out that FCoE might see its first application in inter-switch links and other similar storage network infrastructure connections. And Chris Mellor at The Register points out that SAS is already displacing FC as an internal drive interconnect.

See my posts on Gestalt IT for similar enterprise IT infrastructure commentary

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Reality Check: The FCoE Forecast
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

1. Support for Volume Shadow Copy Service (VSS) for filesystems Windows Server 2003 and Windows Server 2008 guests.  This means VMware services like VCB and SRM can now signal Windows Server to quiesce filesystems before creating a clone or snapshot and is a major addition!
2. Windows Server 2003 guests also get application quiescing, where supported.
3. You can now extend a live, running VMFS volume as storage is added, just like Windows Vista and 2008 guests could already do with raw device mode (RDM).  Note that this only works for flat disks with no persistent snapshots open.

A few items are now officially supported, too:

1. Support for Storage VMotion between and among Fibre Channel and iSCSI datastores is here, and in Update 1.
2. iSCSI over 10 gigabit Ethernet (10 GbE) is now supported allegedly, though the I/O Compatibility Guide still says “Gigabit only”.  Of course, it already worked, but it’s nice to have official support just the same…  Bring on the datacenter Ethernet!  They’ll support this in Update 1 too.
3. And NFS over 10 GbE is supported, too!

1. They supposedly added support for 8 gigabit Fibre Channel (8 Gb FC) HBAs, but I don’t see it in the I/O Compatibility Guide. The Emulex LP12000/LP12002 are noted as 4 Gb only, the QLogic QLE2560/QLE2562 aren’t listed, the HP 81/82 series isn’t there either.  Update:  QLogic and Emulex HBAs are supported after all!
2. Support for more Serial-Attached SCSI (SAS), including Dell SAS 5/E, LSI 1078, Sun SG‐XPCIESAS‐R‐EXT‐Z, and HP SC08GE is listed in the Stotage Compatibility Guide.
3. CIM system health monitoring of some QLogic and Emulex HBAs is new too.

[ad#banner]

See also:

• Scott Lowe’s (as always) excellent overview
• VM /ETC’s colorful post
• Excellent coverage at Yellow Bricks

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Storage Fixes in VMware ESX Server 3.5 Update 2
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.