M. Sean McGee

[...] The State of Statelessness [...]

[...] This post was mentioned on Twitter by xxkickerxx and Dave Alexander, M. Sean McGee. M. Sean McGee said: New Blog post: http://www.mseanmcgee.com/2010/04/the-state-of-statelessness-cisco-ucs-vs-hp-virtual-connect/ [...]

One correction. You list Disk Scrub under security. Disk Scrub on UCS isn't a secure scrub. It only clears the first bit of disk space so another OS install doesn't see a valid partition or installation. It's NOT scrubbing the disk..I wish they'd change the name of that feature in UCS Manager.

Excellent post. One of the main factors that allow the UCS system to provide a greater level of statlessness are the 'built-from-the-ground-up' architechture and some the advantages that affords. The fact that UCS uses a Linux based PXE boot for server configuration allows for things such as firmware modifications and RAID settings. Additionally this makes changes and upgrades of the statelessnes features very easy because the Linux image is stored on the fabric interconnect and upgraded with the manager code (as opposed to requiring firmware upgrades throughout.) Some of the most simple concepts in UCS provide the greatest overall functionality.

Probably good for anyone reading this post to keep in mind the author works for Cisco. Grain of salt required

Hi Chris,
Thank you for your comment. I agree – readers should understand that I work for Cisco AND that I recently worked for HP (all disclosed on the About page). Reading a product comparison from someone who has extensive experience on both vendor's products is usually very useful.

In regards to the grain of salt required… I would agree if this was an “opinion” post. However, this is a “feature comparison” post and not really subject to my opinion – just subject to potential oversight or inaccuracy. I am specifically comparing Cisco's Service Profile to HP's Server Profile and the capabilities each product has. Do you see anything that I overlooked or any feature comparison that is inaccurate? I would be glad to post a correction if you feel this article is factually incorrect in regards to each vendor's capabilities.

I look forward to your response.

Best regards,
-sean

Thanks, Josh. That's a good point. I appreciate the reply.

Thanks for the post, I finally “get” service profiles now and why they're important.

As to the issue of the grain of salt, the problem with comparison charts is that I've seen them used to infer equivalency of a feature where there in fact there are large differences, I've also seen glaring omissions in them too where a relevant competitors feature is mysteriously missing from the table. I'm not saying that this is the case here (from what else I've seen from your blog I'm pretty sure its a fair comparison), nonetheless I understand why people look at these things with a degree of caution.

Additionally this makes changes and upgrades of the statelessnes features very easy because the Linux image is stored on the fabric interconnect and upgraded with the manager code

Question: The CPU is not stateless…..does UCS transfer CPU state across different machines? Does it copy Memory contents between servers? If not, the ONLY thing stateless is the IO….therefore IO is the ONLY thing that makes Cisco Servers (Intel processor, Intel chipset, etc.) any different than HP servers, IBM servers, Dell, servers, etc.

Seems like IO is the ONLy thing that matters

Hi Marcust2010,Thanks for stopping by to read the blog and I also appreciate you taking time to post your comment. I’ll assume that you are from Xsigo since you posted from a Xsigo owned IP address (216.184.50.4). Let’s all try and disclose our employers so that readers understand our perspectives – whether a product vendor, a partner, or a customer.Xsigo ‘needs’ I/O to be the only thing that matters because that’s all that Xsigo does – I/O identity management. Unfortunately, there’s a whole lot more to server identity management than just I/O. That’s exactly why this blog post includes a lengthy chart (http://bit.ly/bX2tjH) showing all the points of identity that Cisco manages – not just I/O, but the whole enchilada.Which of these things does Xsigo manage as part of your identity management product?- server BIOS settings- server boot order (HDD vs. CDROM vs. USB, etc.)- NIC/HBA/BIOS firmware- Remote KVM firmware- Server UUID- Dynamic vNICs for VMware passthrough mode- Fabric Failover- NIC advanced settings – CDP per NIC port- IPMI usernames & passwords plus IPMI user roles- Serial over LAN config- RAID configuration- HBA advanced settings- etc.What Xsigo should understand is… a server’s identity is more than just I/O. A server’s identity is a collection of lots of configuration settings and I/O is just part of that identity.Summary: Cisco manages the entire server identity, including I/O. Xsigo just manages the I/O identity.Again, I sincerely appreciate you taking the time to post. Customers like to see respectful debate between vendors so they’re able to pick the best product.Best regards,-sean

Unless I am mistaken, Xsigo software cannot power a server on or off. It can’t report the inventory of a server blade when it is installed. It can’t launch the KVM console. It can’t monitor CPU temperature or chassis fan speed.

I could go on, but in summary, a Xsigo solution requires that a user log into the OEM’s management tools (different IP address, different credentials, and different price tag) to actually manage the hardware rather than provide a UNIFIED COMPUTING SYSTEM and associated management tools. This is another painful step above and beyond the “state vs. statelessness” concept already covered thoroughly on this page!

Xsigo manages I/O. It does not manage state. It does not manage hardware. It does not integrate with existing tools.

Disclaimer: I am a Cisco employee expressing my opinion and not the opinion of my employer.

I am the Director of Product Management here at Xsigo (enough disclosure for you and happy to have this discussion. Our view is that physical server management is a done deal. customers already have solutions in place to manage the physical server hardware including much of the items on the list you provide (BIOS, Boot order, KVM, UUID, etc. Most customers also already have Storage management in place (something Cisco does not address for external storage). However, when moving into a Virtual Server environment, the CPU, Memory, storage, and networking are all abstracted by the hypervisor…..so the physical server configs mentioned above are stateful for the physical server, but meanningless to the Virtual Servers. The only element that is relevant from a state perspective on the virtual server is how it accesses its shared storage and networking environments. Also, on a similar note, the hypervisor itself does care about how it accesses the network protocol and storage stack….but doesnt really care much about the Server BIOS config…..unless it is dependent on the BIOS config.

The Xsigo approach to IO Virtualization removes the physical IO from the Server itself……so all of relevant connectivity that the Hypervisors and VMs care about are truly stateless and managed outside of the physical server. This is true flexability and true statelessness as far as the IO is concerned. Not only is it truely stateless, but it is the ONLY IO virtualization solution that can virtualize ALL of the IO across all servers, includign Cisco servers. Not even Cisco can virtualizat IO across all Cisco servers…..what about its Rack servers……when will they be supported under UCS and the Fabric Interconnect topology.

Likewise, lets continue the discussion on State….especially fabric state. In the UCS topology, all IO (and server BIOS, etc.) state is managed in the Fabric Interconnect switch. Unfortunately, this model limits the size of the overall fabric to the number of ports on the Fabric Interconnect switch. Today’s limit is 40 ports, but since the total number of VLANs allowed is also limited to 256, this also limits the total size of the Server fabric…..most reps we hear from pitch UCS as a Rack-level solution…..while the Xsigo approach has no limits on fabric size or topology…..Xsigo can have many of its IO directors aggreagated behind hundreds or thousands of servers….not to mention can scale beyond a single fabric hop for storage connectivity (FCoE limited to 1 hop today).

So, if we talk solution comparison, we are talking about Cisco Servers, Cisco adapters, Cisco switches, Cisco Fabric manager to manage Cisco Blade servers and IO…..but lets not forget about Netapp or EMC storage, storage management software, Cisco 2 or 3 other management frameworks for Cisco external switches, Server management for customers legacy servers (Dell, HP, IBM,e tc.)……because I dont really thinnk there are many shops with ONLY cisco servers…….so the broader mangaement framework issues still need to be solved….and Cisco is adding yet another managemnet solution into the mix.

Xsigo plugs in and works with customer existing servers and server vendors (HP, Dell, IBM, Cisco (rackservers))…works with existing Server hardware management frameworks, existing Cisco networking management frameworks, existing storage maanagement frameworks….yet still provides all of the benefits of stateless IO for bare metal and virtualized servers.

Regards,
Camden Ford

Hi Camden,

You said that customers have solutions in place to manage physical server hardware, but I’m not aware of any that are able to do so in a stateless manner. Can you provide an example of a vendor or tool that can move BIOS settings, firmware versions, RAID settings, etc. from one pysical server to another? (other than Cisco UCS)

Thanks,
doron

Hi Doron,

Remember, every Enterprise class server out there has a Board Management Controller either embedded on the motherboard or as a plug in device on the server. HP calls theirs ILO, Dell calls their iDRACs, etc. These BMCs are 3rd party silicon purchased from various vendors…… Intel includes some capabilities in their Ethernet NICs and in some chipsets via IPMI. Using these Board Management Controllers or IPMI controllers over Ethernet, you can issue various commands that can screen scrape, provide remote keyboard access, and even push data into the onboard NVRAM of PCI cards and BIOS chips. Cisco, HP, Dell, IBM, etc. all have BMC capabilities for modifying the configuration of the server hardware. Cisco actually OEMs some software from BMC to handle some of the server configuration and monitoring functionality….it is nothing that is unique to Cisco’s hardware or base software…..although everyone likes to put their own marketing spin on it.

You can easily dig into the HP management software to understand that they can remotely monitor and reconfigure server hardware anyway they like. Now, just to be clear, the BIOS is NOT stateless in a Cisco server or anyone elses server. The BIOS by nature is stateful….meaning that you create a configuration and store it locally in an onboard NVRAM such that the settings int eh BIOS will be there persistently through a server powercycle.

Now, if I have 10 servers that all have identical hardware, in my external management software (UFM in this case), I can set up a small configuration database that stores a specific BIOS configuration. I can designate that has Service Profile A. I can push Service Profile A down to my BIOS through my Board Management controller, reboot my server and it comes up with those settings. I can then take my Service Profile A and push it down to a different server, reboot that server and it will come up wtih those settings….this providing the perception that the BIOS settings have moved from one server to another server….but all I am really doing is writing specific data into the onboard NVRAM device that is read by the BIOS during boot.

All servers with BMCs can do this, but not all of them market as Service Profiles as the mechansim to manage the specific configuration for a given server hardware.

If Cisco has written their own Server BIOS and has developed their own Board Management framework and ASIC to operate in a new and different way from the rest of the world, I would love to hear about it. ROI is usually not there to do such projects….so I am a bit skeptical.

Regards,
Camden Ford

Hi Camden!
Thank you very much for stopping by to read, disclose, and comment. I sincerely appreciate the open discourse.

My view is that Xsigo is focused on “server I/O” only because that’s all Xsigo’s product does. Cisco’s focus isn’t just the “server” and isn’t just the “I/O”. Cisco’s focus is the complete “service” provided by the server, LAN, and SAN infrastructure – kind of like HaaS or physical IaaS. Cisco delivers an ecosystem that manages/monitors/configures/provisions the “service” infrastructure – LAN connectivity, SAN connectivity, and full server hardware identity & configuration management. If a customer wants a plain ol’ server that’s managed the old fashion way via tons of UIs and then they want to bolt on an I/O-only management solution with yet another management UI, then they should choose + Xsigo. But if a customer wants an architecture that provides a role-based, unified management interface to provision/deploy/monitor a complete “service” built on top of the physical infrastructure, then they should choose Cisco UCS as the service infrastructure foundation.

Xsigo, similar to other Cisco competitors, likes to market the “vendor lock-in” message against their competitors – especially Cisco. Marketing folks think the message looks good printed on trade show signs and in marketing campaigns but since when is providing unique, differentiating features from other vendors in the industry “vendor lock-in” vs. “vendor value add”? If a customer buys into something unique that Xsigo does, is that “vendor lock-in” or is it “vendor value add”? Or should I assume that Xsigo doesn’t provide any unique value and therefore doesn’t lock customers in because customers can go ANYWHERE to get Xsigo’s features? I contend that all successful companies provide some type of unique value add and if customers buy into it, they’re locked to that vendor for as long as they want that unique feature or until the feature becomes available from other vendors. At the point that changing vendors is worth more than the unique feature, customers change. Who’s locked in? Cisco provides solution and provides distinct value to customers – but Cisco isn’t the only network vendor or the only SAN vendor or the only server vendor. Customers aren’t locked in. However, if customers like the values provide by Cisco’s combined solution (like buying a fully assembled server vs. piecing one together), then they should buy from Cisco. If Cisco doesn’t provide a value for them, then they should buy from another vendor that does. No lock-in required. Our servers can continue sitting right next to the new servers from the new vendor because Cisco servers are fully industry standard as much as HP, IBM or Dell are.

In summary, Xsigo is TRYING to convince customers that they need to keep managing servers the old fashioned way, TRYING to convince customers to only care about server I/O management, TRYING to convince customers to buy the line about “Cisco lock-in” but not think about “Xsigo lock-in”, TRYING to convince customers to accept multiple, desperate, uncoordinated management interfaces to deploy a single “service”, and TRYING to convince customers that vendors like HP or Cisco don’t need to innovate in the server infrastructure space (a la UCS, Virtual Connect, etc.) so that it’s easier to convince them that the world revolves around I/O management alone. In all sincerity, I understand what Xsigo’s marketing message is TRYING to do. Ultimately, I believe customers are looking for complete solutions, not bolt-on products to solve individual problems. Customers stopped building their own servers from parts long ago. I believe most customers are now tired of building their own piece meal solutions too.

Thanks again for your willingness to openly discuss our respective products.

Sincerely and Respectfully,
-sean

***** Extended reply to some specific statements from Camden *****

**Camden said “Our view is that physical server management is a done deal.”
Sean’s Reply: I suppose this is a key difference in our views. I believe that the same ol’ same ol’ server management doesn’t have to be a “done deal”. It’s a pain in the customer’s rump to use 101 different user interfaces to update BIOS/NIC/HBA/remote KVM/firmware, set BIOS settings, IPMI settings, Boot order, power capping level, VLAN configuration, NIC Teaming configuration, SAN fabric assignment, FC boot target, etc. every time a new server is deployed. Just because it has always been done in 101 different user interfaces doesn’t mean it’s a “done deal” and always has to be this complicated. Have you asked customers how long it takes them to provision a server? The WHOLE server (not just the I/O). It usually takes them weeks. Let’s just take firmware for example, here’s a recent post showing that it takes 40 minutes to upgrade one server (http://bit.ly/FirmwareUpdate). UCS upgrades all the firmware with a simple Service Profile movement. If provisioning the I/O identity is a good idea, then provisioning the WHOLE identity seems like a better idea. Bottom line is – one vendor can manage the entire server identity (Cisco) and another can’t (Xsigo). Xsigo’s marketing message has to be “try and minimize the need for the feature set” because Xsigo’s product can’t compete with UCS on features.

**Camden said “Most customers also already have Storage management in place (something Cisco does not address for external storage).”
Sean’s reply: Xsigo likes to play up the “Cisco lock-in” line because it sounds good…reality is very different. Our ecosystem includes partners such as VMware, Citrix, BMC, EMC, NetApp, etc. Specifically on the storage management front, our VCE solution stack (vBlock) includes both VMware and EMC – and EMC manages the storage. You’re holding it against Cisco for not natively managing storage inside UCS Manager, but if we did, you’d hold it against us as more “Cisco lock-in”. Which is it?

In addition, customer’s don’t typically have a storage management solution that ties together with the WHOLE server identity (not just the I/O identity) so that the two are deployed as a single unit (a la vBlock). Cisco, EMC and VMware make this happen using a single pane of glass using UIM… the foundation is the Cisco UCS Service Profile that allows you to manage the WHOLE server identity (not just the I/O identity).

**Camden said “Not even Cisco can virtualizat IO across all Cisco servers…..what about its Rack servers”
Sean’s reply: Your competitive guys need to update their material. We released the UCS P81E Virtual Interface Card for our c-Series Rack servers. http://www.cisco.com/en/US/prod/collateral/ps10265/ps10493/data_sheet_c78-558230_ps10277_Products_Data_Sheet.html

**Camden said “The Xsigo approach to IO Virtualization removes the physical IO from the Server itself”
Sean’s reply: Replace Xsigo with UCS and you sound like you’re pitching 1 out of about 40 UCS selling points. The point being, Xsigo and Cisco both provide I/O virtualization. However, can Cisco take it even further by eliminating the vSwitch altogether and provide a logical downlink to each VM using VMware Hypervisor Bypass. Does Xsigo provide equivalent functionality? Does Xsigo eliminate the need for a vSwitch/DVS on every Hypervisor if a customer wants that functionality?

**Camden said “but since the total number of VLANs allowed is also limited to 256, this also limits the total size of the Server fabric”
Sean’s reply: Again, your competitive guys needs to update their material. At UCS launch 1.5 years ago, a single Cisco UCS Fabric Interconnect supported up to 256 VLANs – or 512 per UCS system. Many moons ago, that limit was increased to 512 per Fabric Interconnect – or 1024 per UCS system. Check your Thanksgiving Cornucopia and you’ll find that number doubling again. In addition, our customers deploy multiple UCS systems and, due to UCS’s open API, have free mobility of UCS Service Profile’s between UCS systems – mobility of the entire “service profile including I/O virtualization configuration”, not just the I/O configuration.

**Camden said “we are talking about Cisco Servers, Cisco adapters, Cisco switches, Cisco Fabric manager to manage Cisco Blade servers and IO”
Sean’s reply: The world has changed yet again. We no longer drive horses and buggies, customers no longer build their own servers from parts, and most are looking for complete solutions per project – not many disparate products bolted together that require a rolodex full of technical support numbers to solve a problem in their data center.

**Camden said “and Cisco is adding yet another managemnet solution into the mix”
Sean’s reply: And Xsigo isn’t? Also, take a look at the chart I put together above and notice how many management interfaces UCS Manager consolidates into a single UI. We’re adding one and obfuscating many. How many UIs is Xsigo helping to eliminate? Can you provide a detailed chart like mine to help customers understand exactly what they get with your solution?

Camden,

Yes, I am aware of the existence of baseboard management controllers. I was actually on the engineering design team for one of the ASICs that you mentioned. I can quite comfortably assure you that the presence of a baseboard management controller does not make a server STATELESS.

I can also assure you that HP management software cannot remotely reconfigure a server’s hardware “anyway they like.” In fact, HP developed a separate suite of hardware products called Virtual Connect (which directly competes with Xsigo) to try to make their blades more stateless. As you can see from this original blog post, Virtual Connect does not achieve full stateless computing.

To clear up a few things from your reply:

You said: “just to be clear, the BIOS is NOT stateless in a Cisco server or anyone elses server.”

Actually, just to be clear, the BIOS ***IS*** stateless in a Cisco server. The firmware version and 19 different settings from the BIOS can all be moved in concert with the rest of a server’s identity between blades from a single user interface. Xsigo cannot do that.

You said “Cisco actually OEMs some software from BMC to handle some of the server configuration and monitoring functionality.”

Actually, that is NOT true. Cisco UCS is capable of all the things mentioned in this blog post and in my comments without the need for third-party tools. There are many third-party tools that integrate with UCS (including BMC’s BladeLogic), but I don’t want to discuss third-party tools; I want to focus on the things that Cisco UCS can provide for free.

Let me give you a brief example. A server in your datacenter has failed. You’re a Xsigo customer, so you use the Xisgo tool to move your MACs and WWNs as well as your networks and fabrics to a spare server. Now you have to go to a different tool just to power on that spare server. It’s not very convenient. Then the spare server doesn’t boot. That’s even less convenient. The problem is your boot order, so you have to manually fix that. That requires logging into the baseboard management controller (another interface, another inconvenience) to access the KVM so you can change the boot order. The server boots but isn’t performing well… back to your KVM… now it’s a setting in the BIOS that needs to be changed. Let’s reboot the server for that. Then you discover network performance issues and realize that your NIC firmware is at a different version than you’ve used in your datacenter standards. Further investigation shows your HBA and BIOS firmware need to changed, too. Some of them upgraded and some of them downgraded. Another major inconvenience… now you have to go find the firmware management tools. Upgrading is usually easy, but downgrading is not. I could go on listing pitfalls, but the point is that Xsigo manages I/O. Xsigo does not manage hardware.

Now if I’m a Cisco UCS customer in that same scenario, I log into UCS Manager (UCSM) and move the Service Profile for the failed blade to a spare blade. The BIOS settings, the firmware versions (even the firmware version of the baseboard management controller itself), the boot order, the MACs, the WWNs, the QoS settings, local disk RAID settings, etc….. they ALL move to the spare blade. And I did that with ONE command from ONE tool.

Surely you can recognize the benefits of consolidated management — or you would have a really hard time trying to sell Xsigo on the benefits of consolidated I/O management.

Hi Sean,

I greatly appreciate your attention and interest in my comments and for allowing me to post on your forum. I do appreciate you updating me on some of the increased specs on your platform as i havse not had much time to do further due diligence on your system…..but a bit busy as I am sure you have heard.

What I did hear you say very clearly above is **Sean McGee said ” If a customer wants a plain ol’ server that’s managed the old fashion way via tons of UIs and then they want to bolt on an I/O-only management solution with yet another management UI, then they should choose + Xsigo.

Thanks for the endorsement. We will gladly support the 99% of the market with non-Cisco servers with our meager IO management solution.

Regards.

Camden Ford

Cisco choosing to ditch Infiniband for more costly future 40/100G is a disappointment, along with their recurring stiff revenue model. The amount of management done at the hardware level in most shops is insignificant when you are running virtual guests – what used to be a big deal (settings on 40 physical servers) is now set on 1 physical server (with 40 guests).

Proprietary is never good for the industry or the consumer – and seldom for the vendor… Microsoft vs Apple, Microchannel vs ISA, Intel AND AMD, etc. Trying to gain marketshare by being proprietary is kind of like trying to boost the US economy by shutting down our borders so we have to buy US made. It is a great idea but it doesn’t work… open and competitive markets are best for the consumer.

Hi Camden,
You’re crackin’ me up. You sound just like the ol’ horse-n-buggy salesmen…
http://www.mseanmcgee.com/2010/07/the-real-story-about-the-ucs-automobile/

-sean

Hi Bill,
Thanks for stopping by to read and comment.

I’m not sure I follow the Infiniband vs. Ethernet concern. Ethernet is more ubiquitous and, as a result, ends up being cheaper for customers. Both Ethernet and Infiniband are new to the 40/100 Gbps space, so I’m not sure how Infiniband has an advantage there. Cisco, like other technology companies, is driven by market economics – if customers aren’t buying enough of it to make it worth while, the technology vendor moves to the technology that customers are buying. Today, customers are buying Ethernet in an overwhelming majority. Even Xsigo decided to add Ethernet as a supported interconnect technology rather than just sticking with Infiniband.

I decided to poll a few technology folks via twitter. I tweeted “Opinion poll: Infiniband vs. 40/100 GE + DCB. Will Infiniband join Token Ring in the LAN graveyard, stay a niche, or go mainstream?”

@nash_j said: “Niche. I did a good bit of IB testing at the investment bank..even did VMware on it. Niche and HPC.

@jonisick said: ” Graveyard, once RDMA went Ethernet there is no need for a costly complex Infiniband network.”

@vRobM said: “perhaps if IB chips make it onto motherboards.”

@omarsultan said: “@vRobM Economics of enet are hard to beat – cost/benefi of IB on motherboard?”

@asholomon said: “IB is a niche technology. Worked on it a bunch, the issue still is that ethernet is cheap, easy and ubiquitous.”

@suhaibkhan said: “@insideHPC #Infiniband is not going away anytime soon. LIkely remain niche. Expect EDR to be > 100GbE in terms of latency, bw”

In regards to virtualization reducing management of physical servers… I definitely agree that virtualization reduces physical server footprint, and therefore, results in less physical server management. However, the presumption is that there is not a need for physical server management (like what Cisco UCS provides) because virtualization has reduced the number of physical servers. Fortunately for the server manufacturers like HP, Dell, IBM, and Cisco, more physical servers are selling this year than last and the number are only increasing. As such, our customers do have more physical servers this year than last and most can benefit from Cisco UCS’s ability to simplify management of those physical servers.

In regards to the ‘proprietary’ concern… I’m not sure I understand what you are referring to. Are you saying Cisco’s blades are proprietary? If so, I’d agree. Our blades can’t be used in anyone else’s blade chassis. Likewise, all other blade server vendors are proprietary too – their blades only fit in their respective blade chassis and no one elses. Today, all blades are proprietary – form factor, management (OA vs. AMM vs. UCS Manager, etc.), I/O virtualization, features, etc. Let’s take a look at just I/O – Xsigo is proprietary (their features only work with their Directors), HP’s Virtual Connect is proprietary (only works for HP blade servers), etc. In summary, Cisco is no more proprietary than any other blade server vendor. Cisco doesn’t “lock in” the customer any more than IBM, HP, or Dell.

Again, thank you very much for taking the time to read and comment. I’d appreciate any follow up comments if there is anything I’ve said that you disagree with.

Best regards,
-sean

Hi Sean,

Thats pretty funny….because I was thinking you sound a lot like an old IBM salesmen….:-) Mainframes are the future….as long as they connect using FC over Token Ring )

Let me throw one more wrinkle out there in support of IB. Cisco likes to throw out generalizations like…..40Gb/10GbE is just around the corner….or its already here….and paint the picture that Ethernet and IB are roughly equivalent and therefore Ethernet will win. Here are a few key points to consider in this argument:

1. 40Gb IB has shipped more ports than 10GbE (as of end 2009, no data out yet on 2010).
2. Mellanox 2-port QDR (thats 40G for you Ethernet guys) HCA runsn at 8.8W peak, while Cisco Palo adapter 2x10Gb Super CNA runs at 18W.
** Now they way my math works, it appears that a 40Gb SCNA will therefore be (4x18W=72W)….not deployable….or cost effective any time soon.
3. IB switch latency ~ 150ns….Cisco Nexus 5000 switch latency ~ 2us (order of magnitude difference
4. HP just announced putting IB on the motherboard of blades and rack servers for scale out computing – also known as Cloud Computing in some circles
5. Oracle just announced yet another native IB platform called Exascale, for scale out computing using Oracle applications. Thsi is in addition to the Oracle Database Machine (10x faster on IB) and Oracle 11G R2 with native IB support and Oracle Exascale native IB storage.

Now imagine bringing the extreme performance of HPC computing into your Datacenter…..i.e Xsigo brings it all together…..

…..oh yeah…..and for those of you stuck on lower performance, higher cost, and higher power…..we have a 10GbE CEE solution too.

Cam

Hi Camden,
I’ll take that as a compliment. A lot of folks said VMware folks sounded like old IBM salesmen when server virtualization was in the “innovators & early adopters” phases. Obviously it worked out very well for them.

Regards,
-sean

Cam,
I don’t think that’s a “wrinkle” by any means. This isn’t a “which technology should we get rid of?” discussion. This is a “why is Cisco focused on Ethernet instead of Infiniband?” discussion. My opinion is that it’s because Ethernet is ubiquitous, ultimately cheaper, more customer engineers understand it, more vendor ASIC options to choose from, wider selection of products to compete against each other, etc.

I don’t disagree with you that there are niche applications for Infiniband. For that reason, our c-Series servers support IB HCAs. The keyword here is ‘niche’. Infiniband is not a technology that is adopted by the masses and is not the default interconnect technology for the x86 server vendors that make up 80+% of server market share. Why would a company like Cisco put a majority of their eggs in the Infiniband basket? Even Xsigo finally saw the Ethernet light…

This discussion also reminds me of the Beta vs. VHS or Token Ring vs. Ethernet debates. Just because a particular technology has some niche benefits doesn’t mean it becomes the prevailing or default technology.

In summary, while Cisco is focused on the technology that is the mainstream technology – Ethernet – they still provide support for niche techologies like Infiniband.

Regards,
-sean

….but VMware is a software company, like IBM is now. Cisco is trying to become a vertically integrated hardware company leveraging proprietary technology to lock customers into is technology…..very much a “mainframe” mentality. That worked for IBM 40 years ago…..but IBM saw the light and has moved whole hog into the open systems world and beyond….where most of their revenue comes from commodity, open hardware, software, and services……and they do have a small group that maintains their cash cow Mainframe business, but they are no longer investing in growth in that space.

The interesting part is that I would bet that Cisco management is not planning for the Server business to grow very big…..as margins in the server space are relatively thin…..compared to the exhorbitant margins in Cisco’s core switching business. Lets say Cisco grows to $5B in revenue in its server business. That will drop Cisco’s average Gross Margin by atleast 10%…..and the stock will certainly reflect it.

Best of luck, but not too much luck as I will have to get my broker to liquidate my Cisco shares.

Regards,

Cam

Cam,
Respectfully…you seem very out of touch with the blade server market. Not a single blade server vendor is delivering an “industry standard” blade server architecture. Every single blade server vendor’s architecture is proprietary – even IBM. No vendor’s blade can fit in another vendor’s blade chassis. Every blade vendor (even Dell) provides ‘vendor differentiating features’. IBM’s MAX5…industry standard? Nope – only IBM has it. Dell’s FlexMem… industry standard? Nope – only Dell has it. HP’s Virtual Connect …industry standard? Nope – only HP has it. Can a Xsigo customer directly connect their servers to any access switch? Nope, only to Xsigo Directors. Sounds like “lock-in” according to your definition. Is Cisco banging that drum like Xsigo? Nope. We’re focused on our own value-add features. Customers can decide which feature set they want.

All vendors try to deliver differentiating features that inspire customers to keep buying their product vs. a competitor’s product. Does Xsigo provide ANY benefits that no one else in the industry provides? I hope so but wouldn’t that be… … “vendor lock-in”?. Maybe you don’t or you fear getting labeled as trying to “lock-in” customers. Are customers locked into Cisco? Heck no. If they decide that the feature set from Cisco isn’t as good as another vendor, they’re free to start buying Dell servers… and vice versa. Where’s the lock-in?

Just in this blog alone, I think you’ve successfully beat the ‘proprietary’ horse to death and drowned the ‘lock-in’ horse with marketing Kool Aid. Customers like Cisco’s blade server innovation and value-add that simplifies deployment and management of the WHOLE server including I/O- not JUST I/O. Based on your repeated attacks on Cisco for our innovation, Xsigo apparently doesn’t value it. I’d be very worried hearing that message if I was a Xsigo customer… “Did I just buy a product from a company that’s going to be here in a couple of years?” Without innovation (or should I say ‘lock-in’), what keeps the doors open at a technology company? If you say you DO innovate and you DO provide value-add features, then aren’t you ‘locking-in’ customers to those features? You can’t have your cake and eat it too. You want to tell the customer they can buy anyone’s servers as long as they ONLY buy their I/O solution from you. That’s still lock-in…just in a different place.

When vendors focus their competition on innovation and value-add, customers win. That’s has always been, and will continue to be, our focus at Cisco.

Best regards,
-sean

Respectfully…you seem very out of touch with the blade server market. Not a single blade server vendor is delivering an “industry standard” blade server architecture. Every single blade server vendor’s architecture is proprietary – even IBM. No vendor’s blade can fit in another vendor’s blade chassis. Every blade vendor (even Dell) provides ‘vendor differentiating features’. IBM’s MAX5…industry standard? Nope – only IBM has it. Dell’s FlexMem… industry standard? Nope – only Dell has it. HP’s Virtual Connect …industry standard? Nope – only HP has it. Can a Xsigo customer directly connect their servers to any access switch? Nope, only to Xsigo Directors. Sounds like “lock-in” according to your definition. Is Cisco banging that drum like Xsigo? Nope. We’re focused on our own value-add features. Customers can decide which feature set they want.

All vendors try to deliver differentiating features that inspire customers to keep buying their product vs. a competitor’s product. Does Xsigo provide ANY benefits that no one else in the industry provides? I hope so but wouldn’t that be… “vendor lock-in”? . Maybe you don’t or you fear getting labeled as trying to “lock-in” customers. Are customers locked into Cisco? Heck no. If they decide that the feature set from Cisco isn’t as good as another vendor, they’re free to start buying Dell servers… and vice versa. Where’s the lock-in?

Just in this blog alone, I think you’ve successfully beat the ‘proprietary’ horse to death and drowned the ‘lock-in’ horse with marketing Kool Aid. Customers like Cisco’s blade server innovation and value-add that simplifies deployment and management of the WHOLE server including I/O- not JUST I/O. Based on your repeated attacks on Cisco for our innovation, Xsigo apparently doesn’t value it. I’d be very worried hearing that message if I was a Xsigo customer… “Did I just buy a product from a company that’s going to be here in a couple of years?” Without innovation (or should I say ‘lock-in’), what keeps the doors open at a technology company? If you say you DO innovate and you DO provide value-add features, then aren’t you ‘locking-in’ customers to those features? You can’t have your cake and eat it too. You want to tell the customer they can buy anyone’s servers as long as they ONLY buy their I/O solution from you. That’s still lock-in…just in a different place.

When vendors focus their competition on innovation and value-add, customers win. That’s has always been, and will continue to be, our focus at Cisco.

Best regards,
-sean

Cam,
Respectfully…you seem very out of touch with the blade server market. Not a single blade server vendor is delivering an “industry standard” blade server architecture. Every single blade server vendor’s architecture is proprietary – even IBM. No vendor’s blade can fit in another vendor’s blade chassis. Every blade vendor (even Dell) provides ‘vendor differentiating features’. IBM’s MAX5…industry standard? Nope – only IBM has it. Dell’s FlexMem… industry standard? Nope – only Dell has it. HP’s Virtual Connect …industry standard? Nope – only HP has it. Can a Xsigo customer directly connect their servers to any access switch? Nope, only to Xsigo Directors. Sounds like “lock-in” according to your definition. Is Cisco banging that drum like Xsigo? Nope. We’re focused on our own value-add features. Customers can decide which feature set they want.

All vendors try to deliver differentiating features that inspire customers to keep buying their product vs. a competitor’s product. Does Xsigo provide ANY benefits that no one else in the industry provides? I hope so but wouldn’t that be…(ominous music) “vendor lock-in”? Maybe you don’t or you fear getting labeled as trying to “lock-in” customers. Are customers locked into Cisco? Heck no. If they decide that the feature set from Cisco isn’t as good as another vendor, they’re free to start buying Dell servers… and vice versa. Where’s the lock-in?

Just in this blog alone, I think you’ve successfully beat the ‘proprietary’ horse to death and drowned the ‘lock-in’ horse with marketing Kool Aid. Customers like Cisco’s blade server innovation and value-add that simplifies deployment and management of the WHOLE server including I/O- not JUST I/O. Based on your repeated attacks on Cisco for our innovation, Xsigo apparently doesn’t value it. I’d be very worried hearing that message if I was a Xsigo customer… “Did I just buy a product from a company that’s going to be here in a couple of years?” Without innovation (or should I say ‘lock-in’), what keeps the doors open at a technology company? If you say you DO innovate and you DO provide value-add features, then aren’t you ‘locking-in’ customers to those features? You can’t have your cake and eat it too. You want to tell the customer they can buy anyone’s servers as long as they ONLY buy their I/O solution from you. That’s still lock-in…just in a different place.

When vendors focus their competition on innovation and value-add, customers win. That’s has always been, and will continue to be, our focus at Cisco.

Best regards,
-sean

Ok, so riddle me this, Batman:

If Cisco is truly the innovation leader it claims to be and the open systems leader it claims to be….and if UCS is such a leap forward in technology innovation…..

…..why does Cisco REQUIRE customers to run Cisco Voice Apps on UCS hardware ONLY?

Peace!

Robin,
If Xsigo is truly the open systems company it claims to be…

….why does Xsigo REQUIRE customers to run Xsigo’s I/O hardware to get Xsigo’s I/O features?

That’s a ridiculous question and I don’t expect you to answer it. I think Xsigo SHOULD require customers to buy Xsigo hardware (Directors) to get Xsigo’s promised features. Xsigo provides the features that are built and tested to work on Xsigo Director hardware so that customers trust that they have a product that does what Xsigo says it does. The last thing on the customer’s mind is “Hmmm, why can’t I load Xsigo’s I/O software on top of any access switch I buy from Frys?”

Maybe Xsigo should do what DD-WRT does and just release your I/O software compiled for lots of different off-the-shelf switches so that customers have a hardware choice and aren’t ‘locked in’ to Xsigo hardware. Just an idea…

Nice Dance….but you didnt even attempt to answer the question. I think we all know the answer as to why Cisco is requiring Cisco apps to run on Cisco hardware. For all those reading, the specific example I am speaking if is a customer who originally purchased Cisco Voice Apps ….fully qualified on HP blade servers (heck, Sean may have even designed the system for them)…..but now Cisco goes back to the customer and says “….sorry, we no longer support our apps running on that HW you purchased, you now need to purchase new UCS gear to run those same apps”. The good news is that as with much of the UCS sales, the hardware was given away for free to keep the customer from being completely pissed.

Now, the statement above shows that you must not actually understand what Xsigo does and what Xsigo provides. We dont sell servers…we merely sell an IO Virtualization Director. We can connect into any server (except UCS because it does not support industry standard PCI cards) using industry standard Ethernet or Infiniband host adapters and we can provide virtual IO connections out to any existing Ethernet (1G or 10G) switches and any standard FC (1G, 2G, 4G, 8G) switches. We do not specifify that customer can or cannot run any apps on any hardware they like. We do not specify that customers cannot connect to any server, storage, or networking they like….we are completely open and industry standard….and yet we find a way to add value anyways. Think of us as a really smart virtual Patch Panel….you can connect any device into us you want….and if you dont like us, you can replace us….but you dont have to replace any servers, or switches….i.e. Open

Now lets get back to the original question. Why does Cisco require Cisco apps to run on Cisco UCS servers only. That was really a bit of a rehtorical question, of course. We all know that. Its the same reason that IBM requires specific IBm apps to run on IBM mainframes. Customer lock in to vertical solutions.

Now lets take a look at how well that business model as worked for others in teh industry. IBM? Worked great when Mainframes were the only way to solve that problem. Sun? not so much. Dec? Dead and burried. Wang? Burroughs? who?, Unisys?…sounds familiar. I admit, I am beign a bit mean….there are some companies where this model has worked extremely well.

Maybe Cisco really wants to be the next Apple? Not a bad goal. Flip was an interesting acquisition. Is there a Cisco cellphone in the works? Interestingly, Linksys actually had copyrighted the name iPhone first and Cisco licensed it to Apple….was that a mistake?

Cam

Cam,
You sound like the pot calling the kettle black. If you’re going to ding Cisco for selling Cisco software on Cisco hardware, then you need to defend why Xsigo only sells Xsigo software on Xsigo hardware.

It’s your marketing soapbox, not mine. I don’t really care if Xsigo only sells their software on Xsigo hardware… but customer like to see consistent messaging from their prospective vendor.

Cam,
1. Cisco Unified Communications on HP, IBM, and Cisco servers. Your choice:
http://www.cisco.com/en/US/products/hw/voiceapp/ps378/product_solution_overview_list.html

And we (at HP) never sold voice apps on HP blade servers. Unified Communications was only sold by Cisco on HP DL380s and DL320s (rack servers).

2. You sound like the pot calling the kettle black. If you’re going to ding Cisco for selling Cisco software on Cisco hardware, then you need to defend why Xsigo only sells Xsigo software on Xsigo hardware.

It’s your marketing soapbox, not mine. I don’t really care if Xsigo only sells their software on Xsigo hardware… but customer like to see consistent messaging from their prospective vendor.

P.S. I saw a demo of Xsigo’s iPad app today. From what I saw, very cool and very well done. Kudos

Cam,

Are we talking about UCS (servers) or UC (telephony)? Your statements about servers are inaccurate. NONE of the major blade vendors support “standard” PCI slots. The major blade vendors you’ve mentioned use custom form-factor mezzanine cards. Cisco, like those blade vendors, has a custom form-factor mezzanine card but offers industry-standard Ethernet and FC ASIC options on those mezzanine cards (Intel, Broadcom, QLogc, Emulex). In addition, Cisco sells rackmount servers that do have industry-standard PCI cards. So I don’t understand your accusations.

If you want to talk telephony, then your statements on that subject are also wrong. Cisco DOES support UC (Unified Communications) on non-Cisco hardware today. I agree with Sean… if you are going to claim that every application that Cisco sells must be supported on non-Cisco hardware, then please share with everyone Xsigo’s roadmap to enable the Xsigo Manager software to run on a Juniper switch.

Does any company other than Xisgo produce and sell a Xsigo-capable director?
NO.

Does any company other than Xsigo produce and sell expansion modules for the Xsigo directors?
NO.

Does any company other than Xsigo produce and sell XMS?
NO.

Is XMS free and open source?
NO.

So I guess by your definitions, Xsigo represents “proprietary technology” and “vendor lock-in.”

Which brings me to your use of the term “vendor lock-in” in this thread. It is a scare tactic. It is insulting to your customer’s intelligence to suggest that purchasing servers from any vendor forces them to come back to that same vendor for the next purchase.

My Ford Focus came with seats provided by Ford. What an outrage! I shouldn’t be “locked-in” to seats from one vendor! I’m being facetious of course; I’m okay with seats from Ford because my Focus is a system, AND it doesn’t PREVENT me from buying a Chevy for my wife. I just hope my wife is okay with Chevy seats…

But you are taking the conversation a long way away from where it started. Do you want to discuss server and I/O management, or do you want to discuss telephony and Flip video cameras? This blog post started with the assertion that Cisco abstracts server state more completely than any single tool/solution out there. I challenge you to disprove that. And I challenge you to prove that a customer can purchase Xsigo software without running it on Xsigo hardware.

-doron

wow, what a thread! disclosure: I am an employee of Cisco (for one year). What I hear customers ask for is less complexity, more standards, less cost, less variance, less lock-in, less cost… sheesh, they want the world (and why not!). They (the paying customer) tell me that Cisco have got it right (that’s why I joined them). Who are my customers? International Banking, European Retail, UK Gov.

Only the technocrats like “Chief Strategy Technology Officer” give a two-bit toss about this stuff outside of our circles: do the apps guys give a toss? the ones who are by-passing IT to go to the cloud? No is the answer.

It’s about apps, lower cost, faster response, better productivity – across many data centers and across regions.

That means NOT IB or Xsigo. Ciao.

[...] friend, M. Sean McGee, wrote up a great blog post in April that deserves revisiting titled, “The State of Statelessness: Cisco UCS vs. HP Virtual Connect“.  In the write-up, he discusses Cisco how Unified Computing System (UCS) blade servers are [...]

[...] The State of Statelessness: Cisco UCS vs. HP Virtual Connect [...]

[...] covering Service Profiles in this article, but you can read up on them on Sean’s blog here: (http://www.mseanmcgee.com/2010/04/the-state-of-statelessness-cisco-ucs-vs-hp-virtual-connect/). Part of the server’s identity is the BIOS settings and boot order. Additionally, because [...]

[...] Statelessness and why it matters (i.e. why Cisco UCS does it right basically). Nice reference list o… [...]

[...] a blade chassis or groups of blade chassis, not to individual blade servers. If a server is “statelessly” moved using a Service Profile from one chassis to another, a statically defined power cap [...]

[...] Sean McGee has a great post discussing all the items which can be controlled through UCS policies here.  I want to concentrate on just one of them here as we’re discussing firmware management – [...]

Sean, what a great post. Disclosure from my side. I work in VCE (a Cisco/EMC joint venture with investments by VMware and Intel) for a few months but have been a fan of UCS from before that. I found this post by accident but glad I did.

I don’t even think we (all) even do justice to how amazing a work of engineering UCS is. I truly enjoyed this educational post. Keep up the good work.

Imran

[...] UCS 1.0 we brought innovation to the x86 blade server market with Unified Fabric, Service Profiles, Extended Memory technology, a virtual chassis architecture, very extensive networking features and [...]

I appreciate the discussion of the benefits of Cisco UCS and how it may have advantages over competing products.  Can you speak to where you see this having the greatest application?  It’s certainly nice that all these server “objects” are stateless and can be seemlessly migrated to other hardware.  However, this would still require provisioning a new server and rebooting into that new hardware.  So it doesn’t provide the HA functionality of a VM on ESX VMware and it wouldn’t replace a solution like Oracle RAC.  If I’m a good system administrator who routinely keeps an entire environment standardized, why would I choose a Cisco blade over a HP blade?

I’m an end user, by the way.  I don’t work for Cisco, HP, Dell, Xsigo, etc.  I’m simply trying to understand the benefits of Cisco UCS and where it might fit into our environment.  My network administrator is pitching this to me like it’s the best thing since sliced bread, but I’m not sure it gives us functionality we really need and I would have to move to a vendor who is new to the blade market.

Chris- check out the original post- the table shows, with great detail all the possible change points, post blade failure and rebuild, which may need to be touched to mimic the previous config.  I have firsthand usage of UCS and HP Blade chassis, and the WWPN setting, HBA flags are all great pieces to not have to touch again.  The server profiles can also be used well to deploy even more complex blade configs.  I configured one server profile with complicated HBA, BIOS settings, then just made 10 clones that end up with different uuids, mac, wwwn’s etc…   a super quick way to install 10+ ESXi hosts.

So what you’re saying is that while it does provide a stateless hardware setup, I will still need something to provide HA like Oracle RAC or ESX.  That’s my point.  If I don’t require or really don’t see the benefit of stateless hardware, it seems I’m back to debating which vendor I have more confidence in to deliver reliable hardware and value behind that hardware.  After reading up on this for the last several months, I’m having trouble really understanding what extra value this adds to my environment to warrant jumping from traditional vendors like Dell and HP.  I don’t doubt that UCS has features that HP blades do not; I am doubting the cost/benefit side, though.

Chris- I can agree with you- yes you will need something like VMware HA – this is something you could also do with a product like Cisco’s CSS or F5′s big IP – load balance your server.  

I have also though about this independtly, thinking the next huge step would be lifting up the hardware identities, and if a server fails, hardware immediately takes over and continues to present the server configured in the server profile.  Even if other blades are just pitching in, and the server is not at 100% performance,  until a new blade gets configured.

[...] server profile virtulization: Virtual Connect Service profiles allow one to take attributes of a server such as WWNS, MAC addresses, FC boot parameters, etc and store them as a software construct, thus making the hardware itself “stateless”. The Cisco UCS analog to this would be Service Profiles. For a deep dive into the differences, see here [...]

What about Egenera PAN Manager on HP, provides stateless blades. It also
allows for High Availability by providing N+1 Hardware failover. If a
blade has a fatal hardware error the serer profile (stored in xml) is
migrated to a different blade (potentially a completely different blade
model) It also works in Fujitsu and Dell BladeSystems in exactly the
same way.

[...] Sean McGee has a great post discussing all the items which can be controlled through UCS policies here.  I want to concentrate on just one of them here as we’re discussing firmware management – [...]

Would it migrate firmware levels as well? How much extra would I need to pay for this software on top of my hardware cost?

Firmware levels on blades are not controlled by PAN Manager, in our experience so far with HP, Dell, NEC, Fujitsu, and now IBM blade platforms there simply hasn’t been a demand for it. It just works as is. I’ll admit its a very nice feature to have but I have found its not necessary to accomplish automated server profile failover when treating blades as stateless compute resources. However that’s not to say it isn’t something that couldn’t/wouldn’t be added if it really was needed. Egenera could very easily introduce a system similar to UCS Manager where you could assign an update image (or multiple images to support multiple hardware platforms) to a server profile so that the assigned blade first boots via pxeboot (like UCS) or via a bootable virtual cdrom image and this would perform those automatic updates just like UCS the major difference of course is it would be multi-vendor firmware updates in a PAN Manager environment. 

As for assigning bios settings in a server profile the reality is, many of the user configurable parameters included in the UCS Service Profile are rarely modifed in most server deployments.

In our environment we can failover a server profile from one hardware blade vendor platform to another, IBM HS22 to HP BL460c for example. Obviously these blades are from different vendors and will have different firmware levels/bios settings. The point is it can be done regardless. Cisco actually show firmware/bios does not impact the ability to perform failover as you can see in their Virtual Disconnect video at http://www.youtube.com/watch?v=ibMd3ZbvJxQ  where they migrate a HP blade to a Cisco UCS blade, so if firmware and bios settings are really that critical you simply wouldn’t be able to accomplish this kind of task.

As for cost I’ve found a UCS environment with 16 blades is significantly more expensive than a HP C7000 with 16 blades and PAN Manager licenses layered on top. There are also other huge cost savings to be made with PAN Manager that gives you the flexibility of UCS, but allows you to use new/existing blade systems from current hardware vendors and you will not be tied into any particular hardware platform or their management tools so you can switch easily if need be.

Same for Disaster Recover using Egenera’s stateless blade approach one or multiple vendor’s could be used at your production site, another blade vendor or multiple vendors at your DR site. You just import the xml configuration map the server profiles onto the blades and uplinks you want to use and away you go.

I feel “we could do this if…” statement is critical here. Firmware levels play significant role. Inappropriate driver/firmware pair can cause many issues. PAN manager simply won’t provide all possible firmware levels for all hardware vendors otherwise the cost of doing so will be too high. I have seen both quotes for HP and UCS where the latter is comparable or less expensive. Many folks comparing apples to oranges when it comes down to a public price list. Question is, why do I need to pay premium for a subset of features like PAN manager provides if I have all of it plus extra  out of the box at no extra cost? 

BIOS Firmware or settings in my experience have never caused any situations that prevented N+1 hardware failover from working. Also many vendors such as QLogic for example have a unified driver model where firmware is embedded in the driver this eliminates potential interoperability issues between firmware and the driver since the driver loads this firmware into the HBA during the initialization process.

Any way I’m getting off point my initial reply was is in response to Chris_Donohoe who said “I will still need something to provide HA like Oracle RAC or ESX. That’s my point.  If I don’t require or really don’t see the benefit of stateless hardware, it seems I’m back to debating which vendor I have more confidence in to deliver reliable hardware and value behind that hardware.  After reading up on this for the last several months, I’m having trouble really understanding what extra value this adds to my environment to warrant jumping from traditional vendors like Dell and HP. ” My point is you don’t have to jump from Dell or HP, or anyone else. There are options where Dell, HP, IBM, whoever can be managed as stateless computing resources (using PAN Manager or some management platform) allowing you to get the real benefits stateless blades offer such as the ability to perform N+1 failover and not needing to purchase/configure HA/Clustering software, which drives up operational and capital expenditure, and if using SAN or iSCSI storage along with some sort of data replication, it could even simplify Disaster Recovery if booting from SAN/iSCSI.

asdfasdfasdfasdasdfsdf