Folks – we spend so much time fighting, so much seriousness in things that in the end, while important aren’t as important of the lives of people, in particular the lives of children. A friend and colleague at NetApp let me know they were doing a drive for St. Baldricks – a campaign where people shave their heads to help raise funds for fighting cancer in children. So, in the spirit of competition driving positive things and staying above the fray, we made a little wager
|
||||||
|
Happy day for EMC unified customers. A whole bunch of new integration, additional cost savings – all for existing and new EMC customers. Oh, and it’s all free Lots of back and forth with various folks internally on this in the last couple of days, and thought I would just put it out there: Despite the obvious simplicity that would come from directly connecting a UCS to an iSCSI, NFS, FC or FCoE target, this is currently (as of this posting on March 3rd, 2010) not possible with just a UCS chassis and UCS 6100 series fabric interconnect. I’ve had a couple people ask me “why” – after all, they’re just standard SFP+ connectors – you should be able to “plug Tab A into Slot B”. This is not new info (Scott and Rick have hit on this), but since I got asked so much (twice last week at different customers in a New York City tour), I thought I would summarize it here, as our readerships are not the same The Cisco guys do a killer job on these tight, concise TechWise TV episodes… The one this Thursday is on Vblocks. Hari is the main man in the VCE solutions squad in Santa Clara, and Vblock builder – a great resource to listen to, talk to and get to know. You can register here: http://www.cisco.com/en/US/solutions/ns340/ns339/ns638/ns914/html_TWTV/twtv_episode_62.html?sid=188290_26 These EMC IT webcasts are fantastic, and customer feedback has been very positive. They break down the good/bad/ugly of our journey to the private cloud. This week’s session (Thursday, 8am PT/11am ET) is on EMC’s own deployment of View 4. I’m using it right now, and love it! Of course, there’s still a long way to go (check-in/check-out is big for me). I use it all the time to access my lab on the corp network – fire up the View client and I am in the core network (extra secured via RSA, which integrates with View Manager). We’re still in the pilot stages with our View 4/Windows 7 activities (hundreds of clients), but so are a lot of customers. Join in for a perspective (and the upside of the EMC IT folks presenting themselves is it’s not a salesperson As discussed here , in VI3.x, any VMs deployed on VMFS via “clone” or “deploy from template” by default use the “eagerzeroedthick” format. This was the case all the way up to update 5, which fixed this behavior. vSphere 4 “clone” and “deploy from template” operations have always used the zeroedthick format (exception is a VM configured for Fault Tolerance, or where the administrator forces the eagerzeroedthick option – for a MSCS/WSFC device for example). This is important for the reasons covered in that post ( check it out ) – but the key is that it means you use more storage (a lot more) than needed. I’ll add another reason – it literally doesn’t just consume more storage, but it makes takes that do this “zeroing” (clone, template) take a lot longer than they need to. I agree that breaking the storage encapsulation in Virtual Machines is generally a bad thing. What do I mean? That the entirety of the Virtual Machine is not contained in VMDKs stored on some datastore. Examples of this are RDMs, iSCSI in guest and NFS mounts in guest. In general, breaking the encapsulation model is something to do rarely, not frequently. Why? It makes management more complex, makes certain operations impossible (ergo you can’t do a storage vmotion for a device that is mounted via iSCSI in a guest). But – just like all things – there’s a couple reasons why the purists who say “Never!” should be walked away from… slowly… Real world example from yesterday. A customer is using Oracle 11g on an NFS datastore and has 1GbE connectivity. For those of you who read the blog post that Vaughn and I wrote here , you immediately see that you will be bound by the bandwidth (MBps) of a single vmnic on the NFS datastore, as the TCP/IP hashing used for link aggregation only applies if you have multiple TCP sessions, and NFSv3 uses only 2 TCP sessions (control and data) per datastore. So, in the spirit of being a purist, the answer is: Switch to a block datastore (which can parallelize across multiple links via RR or PowerPath/VE) Switch to 10GbE (drive more bandwidth down a single link – a lot more) And if you’re SUCH a purist that you would rather throw out the baby with the bath water rather than compromise dramatic principles: dont’ visualize that workload until a future vSphere release that supports NFSv4 or pNFS. Ok – getting a whole bunch of these things off my chest (business-oriented blog posts), will get back to the lab in a bit This was a internal team gag too funny not to share |
||||||
|
Copyright © 2010 Storage Nation - All Rights Reserved |
||||||
Here’s the PR , but in usual fashion, I tend to like the nerd version. Read on for more! So – without further ado, what’s new and GA?