Virtual Geek

EMC, Storage Resource Management, ControlCenter, VMware and Corporate Culture

I don't think company culture comes from the top down - or from the bottom up.   I think it comes from what people act and what they try to do every day - at every level.   I think people overestimate the ability of the people at the top to cause large-scale change (though it's certainly proportionately higher, and a great litmus test of leadership skill), and I think people underestimate the ability for individuals at all other levels to have an impact.

What's the connection to the post title?   EMC ControlCenter is Storage Resource Management software - and also integrates with the VC APIs and ESX CIM APIs for an end to end view.   There's  a demo here.

So - we have a customer who isn't happy with the state of Storage Resource Management software in general, and ControlCenter quite specifically here.  Ouch.   But, customer is always right (though StorageBod - I have heard that customers are much happier with 6.x than 5.x - but hold us to that).

What I really like is this response from the ControlCenter team - to me transparency is good, and facing the challenge is good.  Specifically - I think it's EXACTLY an example of the opportunity to have an impact.   Storage Resource Management is a challenge for our largest customers - and here you have someone taking the critique, and offering to take MORE - to take that customer input, and make the product the best it can be.  

I run a ControlCenter VM, and Dave, I'll take you up on your challenge.   Get that community open in January.   BTW - our EMC/VMware Open Community Wiki should be up early in the year also....

Does VMware DPM shorten ESX server lifespan?

The inimitable MikeD (http://www.mikedipetrillo.com/mikedvirtualization/) pinged me and some of my colleagues this week with this question - he was starting to hear it, thought it sounded like FUD.   The question is:

"Does the Distributed Power Management power-on/off cycle cause the boot LUNs of the ESX servers to fail prematurely?"

BTW - if you're not a DPM expert, this video highlights it's incredible promise (it's currently an experimental feature in VI 3.5).

The answer in a word?  NO.    DPM does not shorten ESX server's lifespan due to drive failure.

Ok - two comments.   The first is that FUD is always funny (sometimes even our own - and yes, I know sometimes EMC is the FUDer not just the FUDee - though I try as hard as I can to not do that).   The second is that there is more than just the one word answer of course, otherwise it wouldn't be another long-winded Virtualgeek post, would it? :-)

If you're interested.... Read on!

SVVP - how does it work?

There's been some good discussion around this today, and it was good, tomorrow am some official language will come out that will be along the clarifying lines in the body of this post.   Remember, just because I post it doesn't make it official, it's not official until it comes from VMware.   But, this should elucidate things a bit.  

Ok - open standing proposal...   First some history...   EMC has a long experience in working specific customer configurations through the Windows Server Catalog.   Getting MSCS configs certified historically (it's recently gotten a lot better, thank goodness) was BLACK AND WHITE.  Only that EXACT configuration was supported.   For many people this was a deal-breaker.    Over time we got really good This turned out to be a good thing for MSCS as a whole, when you're building these mission critical config, support testing    We became a machine at doing this.   Want a fun proof point?

Step 1 - go here: http://www.windowsservercatalog.com/

Step 2 - click on "cluster solutions" - note there are: 6,792 items found

Step 3 - type "EMC" in the storage field and search: 3,380 items found

You can see that we've done this A LOT - just about half the MSCS configs are on EMC.

OK - here's the open offer - if you are a customer, and the only thing stopping you from adopting a joint VMware/EMC solution for your Microsoft apps is a specific gap on the SVVP that matches you, post your needed config as a response to this thread, I'll work with VMware to get it up there. 

I'm that sure that virtualizing wth VMware is the right thing for customers - I'll get YOUR config tested.   We do have experience on getting this sort of thing done fast.

Ok - for some Q n A - read on.

UPDATED - 9/13/2009 - Some interesting VDI performance findings and updated Use-Case Solution Guides

While much of the discussion and attention will be focused on the very high end VDI scaling cases next week, I thought it would be useful to show some stuff at the other extreme.   We also have been testing in the 125-250-500-1000 user ranges on our NS20, which is an mid-range unified system.   This is something someone could get started in the $30K range.    Note - I'm not talking about what we're doing at the other end of the extreme - the 10K+ use case (we'll talk about that next week).

There is a detailed document that covers these best practices, H5719: "EMC Infrastructure for Deploying VDI in the Enterprise".   The document is on powerlink, and will be up on EMC.com shortly.  The full validation test report showing all the performance envelopes will be up right after VMworld on powerlink.

UPDATE: Folks, the NetApp side has made some comments that in their view we're not being clear here: http://blogs.netapp.com/virtualstorageguy/    Vaughn is a good guy, so I'm going to take the personal slag (ouch - used car salesman) in stride.   We are replicating the LUN objects in this case, and they are the unit of replication.   If you will have more than roughly 200 VDI VMs per cluster, you need to have several VMs per LUN.   The PowerVDI tool automates this.   These ratios mean it's more accuate to say "you will invariably achieve 100:1 space savings, and may achieve more depending on the scaling goal". (the ratio of source VMs per source LUN needs to be higher at higher scales, and therefore 100:1 is the worst case model).   There is NOTHING intrinsically wrong with NetApp's approach, there is NOTHING intrinsically wrong with EMC's approach.   Each have advantages and disadvantages, and are a function of each vendor trying to solve the customer problem.  The ratio of LUNs to VMs is not 1:1.   We don't do this because we love block - while we can take 96 filesystem snapshots, only 16 of those are writeable, so this approach is better for EMC customers. Just setting the technical record straight.

If you want to see some interesting performance metrics - read on!

UPDATED - 9/13/2009 - What we're demoing at VMworld - details!

Some days, my head feels like it's going to spin right off :-)  Thank goodness I love my job!   I'm personally working on some of the last-minute demos - there's some really cool stuff that's under embargo until Wednesday - but suffice it it will be cool!  

My colleague Nick Triantos from NetApp did a good post on what Netapp will be doing, here: http://blogs.netapp.com/storage_nuts_n_bolts/2008/09/netapp-vmworld.html?cid=130026414#comment-130026414

I have to confess, it got my blood boiling a little bit - he accuses EMC of being "All Marketing" and that they will be the largest vendor there.    Please, look at my record, I've been kind, even handed, even complimentary to NetApp, but come on Nick, is that condescending tone necessary?     Tar ME with the marketing brush?!?

Did you know that while we're mud slinging (well, at least I'm getting mud slung at me) that the Large Hadron Collider fired up today?   Man, it's inspiring, and a reminder that this competitive stuff is SO petty.  I'm also pretty inspired by the SVVP "other shoe dropping" with formal ESX 3.5u2 qual getting done.

Ok, so we have a marketing gimmick (the car!!!), sure but heck, it's Vegas :-)   I like to think of us as "All technical, and some fun too"

You'd think that with all this back and forth - it's all we do (well for me - it's 8:51pm, and I've been working all day - so this is a diversion :-)

I will tell you this, it's going to be technical, we're demoing like mad, and there are some MIND BLOWING things there.

We're in booth 500, and I look forward to seeing you there.   What you can expect to see:

• Demonstrating Oracle 11g and SAP with instant/backup recovery and Site Recovery Manager all in action together  (BTW - thank you all who have been so interested in the Oracle piece that it got oversubscribed and we've been asked by VMware to schedule a second session on EA1961)
• Demonstrating Exchange 2007 Joint VMware/EMC reference architecture including VSS backup/restore, CCR and LCR use cases
• How all our management tools (Storage, Network, Application Dependency and VMware Best Practice compliance analysis) integrate with the VI 2.5 SDK and ESX CIM APIs - TODAY.   Our view is that customer need to start virtualizing tier 1 apps - and we want to help - with the joint best practices and with tools to ensure you get applicaiton-level SLAs.
• Replication Manager for VMware - instant VM or datastore backup/restore - integrated with the VI and ESX APIs for nice simple point in time consistency.   As a company that's not as good at marketing as others, we quietly actually shipped this BEFORE ANYONE ELSE.   It wasn't pre-launched, it shipped in June.   Here's  a quick look if you want to see what it does.   BTW - this is a single tool that does this for application integration Exchange 2003 and 2007/SQL Server/Oracle and now VMware, and across all EMC's platforms.   Here's a demo....

• VDI - great to hear that NetApp hit 5K clients. We just broke 10K :-)  UPDATE: I regret phrasing this sentence this way - it comes across as snide and as condescending.   I let frustration get the better of me.   NetApp has no intrinsic scaling limit that I know of, I only know what we can do.   BTW - that's what this standing lab in Santa Clara is there for - for EMC and VMware to jointly prove these out at scales (target of 40K clients).    BTW, we're also doing this at 500, and 1000 client cases.   It's not a chest-beating exercise - customers come in all shapes and sizes, and we're trying to help prove out how this works for them all, it was triggered by the World Bank which asked for us to show how this would work for 20K clients.      We have a similar (but different - each with advantages and disadvantages) approach as NetApp - mass scale with consumption of one, both how we do this today, and also how we do it with VMware tomorrow.    We will be sharing all our performance scaling data, and experiences.   THIS IS BLEEDING EDGE.   Anyone who tries to tell you that this is all figured out is not giving you the whole truth.  Anyone who just shows you the array side of the equation is flat-out dangerous.   When you push this far,  and all boot simultaneously, sometimes VC gets into a weird state on some of the VMs.  Its fun, and continues to be fun.   BTW - here's a cool screenshot (count up the VMs - there's actually 10,994)

UPDATE: Folks, the NetApp side has made some comments that in their view we're not being clear here: http://blogs.netapp.com/virtualstorageguy/    Vaughn is a good guy, so I'm going to take the personal slag (ouch - used car salesman) in stride.   We are replicating the LUN objects in this case, and they are the unit of replication.   If you will have more than roughly 200 VDI VMs per cluster, you need to have several VMs per LUN.   The PowerVDI tool automates this.   These ratios mean it's more accuate to say "you will invariably achieve 100:1 space savings, and may achieve more depending on the scaling goal". (the ratio of source VMs per source LUN needs to be higher at higher scales, and therefore 100:1 is the worst case model).   There is NOTHING intrinsically wrong with NetApp's approach, there is NOTHING intrinsically wrong with EMC's approach.   Each have advantages and disadvantages, and are a function of each vendor trying to solve the customer problem.  The ratio of LUNs to VMs is not 1:1.   We don't do this because we love block - while we can take 96 filesystem snapshots, only 16 of those are writeable, so this approach is better for EMC customers. Just setting the technical record straight.

 

 

• Here are some datapoints from the VDI testing to date:
  • there are limits to how fast ESX and VC can register vms (hostd dies) and how many you can spawn simultaneously - discover the what we've done jointly with VMware on this!
  • XP Booting causes 4000  IOs spread over 20 seconds.   That is 200 IOPS per Client Sustained during the boot….   Multiply that times 100 for a server…… 20,000 IOPS.    Or multiply it out to a moderate environment of 1000 desktops.     200,000 IOPS all directed at the Array.    How much hits the backend vs cache effect?   What is the client experience?  Come and find out!  (BTW this will be a big topic in session PO3824 - "Storage Solutions for Enterprise Consolidation with VMware")
  • BTW - Congratulations Dan for coming in 3rd in VMware's PowerShell contest for the PowerVDI tool we created for this.   The quote was great: "Here's what Lee Holmes, author of the Windows PowerShell Cookbook had to say about it: "Automates a very complex scale-out task, and combines a lot of technology (VMWare, Putty, AD, etc) into a single PowerShell task. Offers interactive use, unattended scripting. For high-scale clusters, this would be an enormous time-saver. This script really demonstrates the super-glue nature of PowerShell."   Dan, you'll laugh man, but a large NetApp customer asked me for the script... wait until we unveil what's coming next!   For those of you wanting this script, note that we've posted it openly for all.
• Deduplication, and simple file-level recovery for Windows/Linux VMs
• NFS and iSCSI deployment best practices
• Joint EMC/VMware Remote/Branch Office solution
• Several of our Partners (Agilsys, Fusionstorm, ICI and others) will be present in the booth to show their integrated solutions.
• We will be demonstrating several things I can't even allude to as they are under an embargo until the event.

We will have 70 people at the event, including myself, but also our engineering teams directly - including Bala Ganeshan and Sheetal Kochavara who are the engineering folks who maintain our DMX and CX best practices, along with our Field VMware Specialists (all VCPs from around the world.  

I don't know what any other vendors are sending equipment wise, but I've sent 13 CX3s, 4 CX4s, 3 NS20s and 2 DMX4-950s.   Those will be in lots of places where you can use them, including the hands-on labs, and in various booths.

I can wait to talk to YOU, and of course with our competitive brothers and sisters!

Oh, and our keynote  (where all are welcome!) is KN EMC on Wednesday at 11:00-12:00. It is a joint VMware/Cisco/EMC session discussing best practices for designing the next generation datacenter with Scott Davis from VMware and Ed Bugnion from Cisco.    It's three nerds on stage - a recipe for trouble!      I asked to do a show release to show what we're doing at the event, but our PR folks told me that unless a senior exec is doing the Keynote (like Dave Hitz is for NetApp - and they did a press release), we don't do those.  I'm just a technical guy, so I don't qualify :-)

Just to show the ridiculousness of it all, NetApp's press event got scheduled at the same time as our keynote.   We intentionally moved ours to avoid conflicting with theirs because we know some people will want to go to both.   I'm going to keep pushing the kind agenda, because I don't think pettiness helps any of us.

Nick says:

"For NetApp this will be the largest event of the year and like everybody else we've been preparing for it for some time now. This year, by far, we'll have the largest presence in the show and we'll be ready to showcase various technologies that solve some very real and hard to solve business problems."

UPDATE: Nick has made a fair clarification of his intent  of the statement, and I trust him in his clarification.

Nick - looking forward to meeting you there and getting to know you.   This is our biggest event of the year also, a bit bigger than EMC World which had 10K customers.   I don't know if we'll have the largest presence at the show, but I can tell you that you are not in a position to make that statement that you will be until after the show ends, right?   Statements that are not true?   I call that Marketing.

.

.

.

OK, I can't help being a bit petty.

Remember the whole brouhaha about the IDC data back here?  

So, on Sept 8th, Goldman Sachs released their annual survey analyzing IT spending - the "Independent Insight"  here's how THEY describe it.

"This is the 42nd issue in our IT Spending Survey series. Our survey panel is made up of 100 managers with strategic decision-making authority at multinational Fortune 1000 companies."

Ok - so note (I don't want to misrepresent!) note that this is FT1000 (we're doing excellent in all segments - but I don't want to imply anything about other segments, take it what it is, no more, no less)

First, for my VMware brothers and sisters - congrats:

"VMware’s incumbent position at the top of the rankings demonstrates that server virtualization momentum remains alive and well."  (Microsoft - watch out for the wrath of Nick, showing Live Migration when Hyper-V R2 is scheduled for a 2011 release is called Marketing)

Nice to see EMC Software (which excludes VMware) also in the gainer column - our management tools are flying off the shelves, in some part due to their integration with the VI SDK and ESX CIM APIs.

I liked this, of course:

Does that look like it agrees with the IDC data from earlier to you?   Look also at who went up and who went down.

Oh, and then here's this hot off the presses too: http://www.idc.com/getdoc.jsp?containerId=prUS21411908   The NAS numbers and growth numbers are stunning.

LET ME BE CLEAR: I THINK NO CUSTOMER SHOULD PICK A SOLUTION PURELY BECAUSE OTHERS DO.   Every customer should pick solutions that work for them.   What I am saying is you can't produce those results and outgrowing those that are smaller, and do it across categories if you're not doing something right for your customers.   To believe otherwise is to shrug off reality, and to become one of those "extremeophiles".

Look, I want us to focus on helping the customer.   Nick - I'm good with that if you are - sincerely......

I will be in some NetApp sessions (and in VMware labs, and in other sessions I'm interested in).   I will not heckle - though of course you guys are welcome to in my session (leave my colleagues alone).   I'm respectful and want to learn from you and with you.   But I won't take mudslinging at EMC lying down - in the same way that you guys shouldn't (and don't) when we do it.

Welcome - My friend, NetApp's Vaughn Stewart

We may face each other often on the battlefield, but I relish every battle :-)   My good friend an colleague Vaughn Stewart has joint the blogosphere - check it out, and add it to your reader!.   Vaughan - welcome, and drinks are on me at VMworld!

Vaughan, I love ya, man - but come on (seriously) on TR-3697  - it's like something Chuck would make :-)  I love NFS storage for VMware - it doesn't get the love it should, I love iSCSI storage for VMware, I love FC storage for VMware, I love FCoE storage for VMware (and on this one, although I literally have at least a few grand riding on iSCSI, I've come around to the "it's not a conspiracy" view like Dave has here - though "wait" is subjective - VMworld is right around the corner).   So long as it's storing VMs and the customer is happy, I'm happy. 

But seriously....

"The goal of this testing was to compare the throughput capabilities of ESX 3.5 with NetApp storage using FC, iSCSI, and NFS protocols in a real world environment."

Ok, if that's the case, what's the scoop with:

• 4K/8K IO size only
• 2Gbps FC
• You guys have "throughput/IOPs" shown only in relative, not in absolute.
• 84 144GB drives with 16 VMs driving the IOMeter workloads with * 10GB of data each on them =  1.3% utilization (rounding up!).  

This is a workload and a comparison chart that Netapp dreams of - but unfortunately doesn't match the noble testing goal.   I love NetApp filers.   I own them.  I have bought them with my own $$.  What they do they do extremely well - but WHY do you guys insist on running workloads in these benchmark docs with these crazy low utilizations??

WAFL = greatest strength in some use cases; greatest weakness in others. That's not BAD, that's engineering.   Engineering is all about tradeoffs.  

WAFL's tradeoff is free snapshots in exchange for non-linear performance under normal workloads and normal utilization.  It's your superpower, and your kyptonite.   Kickass write perfomance when there are loads of free spaces to write to.   Another manifestation is post-process deduplication - but not not pre-process (which no one has figured out for production storage but is our goal) which is really another GREAT manifestation of WAFLs underlying characteristics)    Good read performance overall.  Poopy write performance when it's random with a full and fragmented filesystem.    

BTW - do NetApp filers catch fire under this condition - NO, but they do slow down.   In the same way our arrays don't catch fire with snapshots (as much as you guys say they do).   But both are designed for different tradeoffs.

Again - that's not bad, that ENGINEERING - it's all about trade-offs.    EMC has many of the same sort of things, in different places.   You guys make great platforms, so do we.  

Come on, let's not be Chuck here.  If you wanted to be real-world - let's do a broad set of IO sizes... you're a smart dude (you REALLY are) - so let's see it at 64K (the current max, larger than that and ESX starts chopping them up.   Let's see that a 10%, 20%, 50%, and 80% utilized.   Let's see it after a few days of random workload.

I would expect you would see the same thing I see, and the same thing VMware sees (this is covered here - btw, this doc is flawed also - broad IO ranges, but 100% sequential write and read only - but I don't feel bad, those are workloads that favor WAFL over traditional block layout schemes):   

Let me summarize (both TR-3697, EMC's docs, and VMware's docs agree!):

NFS and iSCSI are fantastic and near FC in throughput and IOPs on small (4/8K) IO workloads (though consistently higher in CPU utilization - though MHz are close to free these days), but they diverge (this is not bad, it's expected) at large IO sizes, and large througput workloads - even with 2GBps FC (which is the chart above from VMware) - which no one even buys anymore.  This is different with 10GbE and jumbo frames of course.

When you publish a benchmark that shows "we filled this to 70%, ran it with a random write workload for 3 days, and THEN ran the benchmark, and we compared it with current FC technology", you can come over for dinner :-)  Ok, screw that, I'll buy dinner AND drinks at VMworld!

Ok, that off my chest, I will NEVER let my blog (or me) devolve to being anti-NetApp.  You guys are a great company, a great competitor, and are filled with great people.   I relish competing, because it brings out the best in both of us (except silly stuff we each do to compete with each other) and that's good for us both, but more importantly, good for customers.  I've said it publicly before, I'll say it again:

My comment:

"For what it’s worth – personally, certainly I don’t necessarily represent EMC in this context – I appreciate having as formidable a competitor as Network Appliance. With other competitors, we compete with them, and it’s a slow waltz, but with you folks, it’s a tango. It makes us better, win or lose with any individual customer, and in the end, it’s good for the industry and the customers."

And Dave Hitz' comment:

"I completely agree. I feel the same way about EMC."

SVVP - Thank goodness!

Take a week off, and sometimes you come back and things are a mess, sometimes things are better than when you left :-)   I'm a little more tanned, a lot more relaxed, and have a sore set of muscles after a week of windsurfing.   But, as happy as I am about that (and a week with my wife and kids!), I'm more happy about something else.

Thank goodness for the Server Virtualization Validation Program.  http://windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm

One of the bugaboos in what is undoubtedly one of the best things to happen to IT in the x86 space (ahem, virtualization generally, and VMware specifically if you didnt' read the title of my blog) has been ISV support.  It's also hard to find a larger ISV than Microsoft.  

For the longest time, the grey question of Microsoft was such a consistent refrain, I memorized the governing KB article: KB897615.   You have to trust me that I'm not looking it up - but trust me - I just typed it from memory :-)

It didn't say "NO!", but it didn't exactly say "YES!", or say "NO/YES!" (like Oracle's Metalink articles which are "Yes" to Oracle SE or EE single instance ,but "No" to RAC).  What it said was that they would provide best effort support for Premier customers, but reserved the right to repro in a physical.

So, what's changed, what does this mean, and what are funny pictures that make the point?   Read on!

ESX 3.5 Update 2 Bug, Express Patch, and Quick Thoughts

Ugh - yesterday was a tough day.   My team is a global team, and the phone started ringing and emails started pouring in as soon as clock ticked over to Aug 12th in Australia.    The only reason I haven't posted earlier was I was up to my eyeballs.

The issue is in this KB here   While it was rough on me as a VMware partner and as EMC as a VMware customer (you can see from my other posts we have thousands of ESX servers, and while production goes through a change control process and is on 3.0.2 and 3.5u1, our solutions validation and demonstration labs update as fast as possible) - people at VMware are in agony.

I don't want to write a big post on this - great ones have been written at some of my favorite places - here, here (Alessandro at his hyperbolic best), and here.

Before you go any further, get the express patches here, and you can see Paul Maritz's comments here.  

I think a lot of people in the blogosphere are extremophiles, defined this way:

""An extremophile is an organism that thrives in and may even require physically or geochemically extreme conditions that are detrimental to the majority of life on Earth."

Many of the comments on VMTN just break your spirit a bit until you harden yourself.    Anger/frustration are reasonable, but anonymous posters and fan-boys, I have little patience or respect for you (though I doubt you care)   Strong feelings are good - passion is good, but don't hide if you feel strongly about your position, and you think it's reasonable.

I'm getting hardened to it a bit - along with Intel, Cisco, Microsoft and other big players, EMC get's a lot of flak from these kind of folks - people want the small guy to beat the big guy, and revel in it, and like slinging mud.

VMware is a weird exception - they are the 800 pound gorilla of their space, but it happened so fast they maintain the "startup" halo around them.   This inevitably changes as growth happens, they solidify themselves as a key in the new IT infrastructure space, and new startups work the david/goliath story humans love.

Here's one person's opinion - no more, no less.

1. This sort of happens to all companies - great/weak, small/large.   I'm not blasé about it, it's a terrible thing.   The real test is how the organization deals with it - are they open, transparent, fast to fix, and afterwards, do they improve their process?
2. If it happens with ANY frequency, regardless of the company, there are serious problems - we are all only as good as our products.
3. The way to reduce the risk to your IT infrastructure from this if it really is inevitable is to implement change control.   A classic example is that Enginuity is currently at 5773, but DMXes ship with 5772 code for now.  The same holds true with all our platforms - there's a window we called a PPR - "Phased Product Release".    Even long established processes, we've STILL been hit (there was a similar date-based bug in the Kerberos code used by our CIFS server a while ago).   Customers implement their own version control on top of what we do.    The only reason customers hasn't been behaving that way with VMware has been that their software quality has been SO good.

Let's look at this case:

1. VMware has clearly been open, transparent, and clearly aggressive with their fix, which was made available late in the same day.
2. This is a first for VMware.   A bad first no doubt, but still a first.   The question is whether the first of more to come, or an isolated incident.   While I may be biased, I think they deserve the benefit of the doubt based on their history of quality.
3. Every customer needs to apply good IT best practices on change control of all parts of their mission-critical infrastructure - VI is no different, and arguably one of the most important ones to do this with - because, like core network switches and storage infrastructure - it's hyper-consolidated.

What was your experience, and what are your thoughts?   Extremophiles welcome, but rationalists desired :-)

"What's in a study" - Redux

If you're a technophile, stop reading this post right now :-)   This is a nit, but since I posted earlier on this little saga, and some folks LOVE getting a peek into the insider sillyness , here goes....

To recap - EMC was using a slide that all of a sudden we we asked to stop using by IDC.  I talk about that here.   So, we got the formal approval from IDC what we can use, and I've passed the edict to our field to update.   These are all public docs, and ones EMC folks and EMC partners present to thousands of customers every day, but still... want to see the before and after? Based on what IDC told us we can and can't do - it's a huge difference.  It also strongly suggests where the complaint came from.   I have to get this off my chest, and then back to technical action (I'm working on a DOOZY of a post)..... Read on.

 

Virtualizing Sharepoint - How about saving 74% of your power?

Folks - we have talked a lot in the past about Exchange 2007 workloads on VMware Infrastructure here (net: Exchange 2007 on VMware works GREAT, you can get more users per server than you can on physical, you can get all the goodness of the new Exchange 2007 features without the server sprawl they create, and still get all the storage savings).   Some folks have asked where they can get the detailed doc, including performance data.  Read on for directions on how to find ALL the solutions docs(i.e. "teach someone to fish") - but if you're lazy, just download it here (also to just to stop the "EMC doesn't share detailed info" doubters out there). 

BTW - there is more to come on that front - we still shattering our own current records of 16K users per ESX server (configured as 8 mailbox server role VMs each with 2K users) as new server platforms hit the market (last round was with the R900 series server with 64GB of RAM).

Now on to another "Tier 1 app".... Sharepoint is another great app, and a great app to virtualize since it's one that often has a lot of server components (like like Exchange 2007) and people were asking about our experiences running it on VMware.   Curious?   Read on....