I mentioned in this post that we just passed the one year anniversary of VxRail, and it is cooking. 8,000+ nodes. 100K cores. 65+ PBs of storage. 70+ countries. And we’re just getting started.
We’ve resolved some of the “we can’t ship them fast enough” issues. Believe it or not, we still have some configurations only available in 14 countries and not available in fed. On it – global availability is soon. We’re working on the “we can’t install them fast enough” (backlog) issues ourselves and with our partners. It’s been amazing even with all those challenges – people like the formula. And now, like all successful products we have our first major “everyone deploy this right now patch”.
VxRail customers – read this and follow.
If you go to the VxRail support page: http://www.emc.com/vxrailsupport, you will see this in the “Advisory” section.
There is also a formal ETA (EMC Technical Advisory – suppose this needs to become a “DETA”):
ETA 496692: VxRail: Upgrade VxRail systems running version 3.5 or 4.0.x to VxRail version 4.0.132 to incorporate VMware ESXi 6.0, Patch U3 ESXi 600-201702201, which addresses potential data unavailability or performance issues.
This is important enough that we are also issuing an FCO (Field Change Order). This means that we will immediately change every one leaving the factory, every one that gets installed, and engage with each customer to make sure they upgrade. It’s important.
We work to make sure that the VMware team and our VxRail/VxRack SDDC teams work as one (they are one). The goal of that team is to have THE BEST HCI Appliances (VxRail) and Rack Scale Systems (VxRack SDDC) for customers who have standardized on VMware. It’s not for everyone (some want “heterogenous HCI offers” like Dell EMC XC and Dell EMC VxRack FLEX) – but customers want to know we’re tight. We are – we work furiously to be near-synchronous and plan many, many quarters in advance. The team is ONE TEAM. Amongst other fixes in VxRail 4.0.132, there are critical performance improvements and DU fixes due to the fact that the update rolls up vSAN 6.0u3.
Beautiful thing about HCI is updating is cake. Any customers running 4.0 with Enterprise licensing don’t need any help – they can simply do it themselves – and that’s the majority of customers.
If you are running older versions, or have Standard edition licensing (this has to do with dVS vs. the standard vSwitch) – just contact Dell EMC Support, who will help you.
If you want more details (again, there’s more in 4.0.132 than just the vSAN update, but that’s the key piece behind the urgency), it’s available through VMware KB article vSAN performance enhancements delivered with vSphere 6.0 Update 3.
Additional information on fixes and enhancements in vSphere or vSAN can be found at:
Refer to the following VMware KB articles for information on issues referred to in this ETA.
- De-stage process can result in poor performance in vSAN deduplication environments
- vSAN host may encounter a purple diagnostic screen during resync operations if resync is paused
- vSAN host may encounter a purple diagnostic screen during performance statistics updates
- vSAN hosts may encounter a panic screen (PSOD)
- vSAN 6.2 increase in used disk space with All-Flash and Deduplication
- Frequent internal calls to the vSAN API results in a large quantity of VASA messaging in vCenter
- ESXi host fails to rejoin vSAN cluster following reboot
- Component metadata health check fails with invalid state error
Have you updated? How did it go? What (as always) can we do better?
Chad I'm confused with what you're saying about DVS - I believe(d) that VxRail and vSAN comes with Distributed vSwitch licensing, and it was configured with DVS out of the box? Regardless of your vSphere license SKU
Posted by: Mike W | March 07, 2017 at 08:37 PM
Can't wait for 6.5 support
Posted by: John Ford | March 14, 2017 at 06:50 AM
Mike W you are correct. VxRail always deploys with vDS regardless of the version of vSphere (license applied post-install). This is thanks to the vSAN Enterprise license that's baked into the VxRail platform.
VxRail's update feature (aka rolling updates) relies upon DRS for workload placement when automating the Maintenance Mode operation. Thus we have a safety feature embedded into the update process that needs to be overridden by Dell EMC support when using another vSphere edition (standard, ROBO).
Posted by: Gordon | March 17, 2017 at 04:20 AM
Finished yesterday upgrading VxRail (from 4.0.100 to 4.0.132). I am pleased that it was a success. Doing a Full Stack upgrade with one click is for me "the killer feature" that made us choose VxRail over any other vSAN Ready Nodes. Over are the times that we took a month to upgrade one Infrastructure.
To improve VxRail further, I would suggest during deployment to have the ability to choose VM Names, DC name, Cluster Name and Datastore Name. Using the default ID's makes things ugly. Also, there should be an automated way to deploy ESRS (and VxRail should also be able to upgrade it). With this we would really achieve an end to end upgrade.
Other than that, I am pretty happy with the outcome :).
Posted by: Peter Figueiredo | March 28, 2017 at 04:39 AM
2 for 2 going from factory 3.5. The only issue was a vSphere incompatibility with the RP4VM plugin. This KB (https://emcservice.force.com/CustomersPartners/kA2f1000000RMJsCAO) addresses the issue but it really should be fixed coming from the marketplace.
Posted by: LehrnerLV | April 08, 2017 at 06:15 PM