Accepted Solutions
Some good ole' best practices for isolating VMotion on it's own physical interfaces and switches could make this all a moot point. 
At least then the solution could span multiple network hardware providers and require less complex config, but at the expense of more ports and switches. Will be interesting to see further guidance come out.
Sean Clark - vExpert 2009, VCPx3 - http://twitter.com/vseanclark - http://seanclark.us - http://vmunderground.com
Isn't fixed bandwidth allocation per vNIC a form of QoS? Plus from what I head here - http://bradhedlund.com/2010/08/16/cisco-ucs-qos-vs-hp-virtual-connect-rate-limiting/ it seems that the Flex-10 implementation is pretty static...
I would think a WRR based scheduler with a bucket per traffic class would be pretty darn simple and allow a much more fair bandwidth scheduling while, as you rightly point out, not being a pain in the bottom 
(agree completely on the assertion that most QoS implementations out there are overly complex for the task at hand- major room for improvement in most of these...)
dg
You have to split this problem into two parts, it's not just about the Host NICs - it's about (a) Host Bandwidth and (b) Network Bandwidth.
The days of many dedicated 1GbE ports are going, going gone. New thinking is required for 10GbE, so let's all take a step to the left.
Every platform (HP, Cisco) can do rate limiting on NICs, and now with VMware's NetIOC you can do it from the hypervisor. That bit is easy, but it's only the start of the story.
As Aaron has said elsewhere, this is not just about Vmotion! Vmotion is the obvious candidate for saturation and that saturation is not just for one host's bandwidth, it's also for the Rest of the Network. It takes two-hosts-to-tango to do Vmotion, so that 8Gbps is going via a network somewhere. Imagine 16 hosts doing 8 simultaneous Vmotions - the network has to now do tens of gigs of vmotion traffic. What if there are other busy traffic types that are business critical? What if you are running Unified Comms on the network? What about FCoE?
THere is also the problem that rate limiting is a hammer/nut solution. Allowing VMotion to consume as much bandwidth as possible is a Good Thing - AS LONG as it doesn't saturate it and hurt other traffic like UC, HTTP, DB, FCoE. With rate limiting you are hurting VMotion (or any other traffic) and in $$ terms you are not getting a good enough ROI from your expensive, virtual network. Do you do individual VM limits/reservations/affinities today? That is the equivalent of rate limiting a NIC on the network It's easy but not necessarily right.
QoS is only complicated when it's new, but it's a bit like Jumbo Frames in that it has to be done properly and consistently, but it needs more design work.
QoS is also inconsistently implemented by vendors, even within a vendor it can be done differently on different products.
So, as a Cisco employee I want to make this more transparent and easier for non-networking guys to get a handle on - and so does Brad (see hist post), and Aaron who's not a Cisco employee but is a rockstar working for a great partner.
But back to your point - yes you can Pipe Carve with HP (you can do it with Cisco UCS too) but it isn't the answer, more of putting a bandaid on a deep crack in the wall of a dam