VSAN with AHCI controller with vSphere 5.5 U2

I’ve been following a thread on the community forums closely around the AHCI disk controller. This disk controller is an on-board disk controller which caused some problems when used in conjunction with VSAN because of a driver problem. Note that this disk controller is not on the HCL and is not recommend for use in a production environment or ANY environment where reasonable performance is expected and endurance / availability is key. Many homelabbers used this controller however and I am happy to say that it was reported by Philzy that this fix mentioned in KB 2079729 appears to have solved the issues experienced.

For all those wanting to use VSAN in their homelabs… Game on!

EVO:RAIL vs VSAN Ready Node vs Component based

EVO:RAIL is awesome! That is typically what I hear from customers when pitching the EVO:RAIL play and showing the config and management demo. Customers are all over it I can tell you. They love the ease of deployment, management, procurement and support… Now, every now and then this geeky person pops up and say: but euuhm, I want more disks and I want to scale per node and all of my configuration stuff is scripted. How will that work with EVO:RAIL?

This is when I show them this slide:

It is a very very valid question to be honest. It is something which I, as a geek, would ask as well. How can I tweak the configuration so that it meets my requirements, and can I just use my own deployment mechanism? Sure you can, but not necessarily with EVO:RAIL. Keep in mind that EVO:RAIL is build using trusted VMware technology like VMware vSphere, vCenter Server, Virtual SAN and Log Insight. Although the EVO:RAIL engine (configuration and management interface) cannot be downloaded separately the components can be. We very much realize that EVO:RAIL may not be a fit for all customers and that is exactly why VMware offers choice as the slide above shows.

If you are a geek, love digging through hardware compatibility lists, like to configure your own servers part by part and have absolute maximum flexibility then option 1 is your best choice. Using the “Component Based” approach you can select your own: Server (vSphere HCL) and then from the VSAN HCL pick your components like the disk controller, SSD and magnetic drives. You get to pick how many drives, which type of flash, how much memory, how many cores per CPU… you name it. Note though, that it does mean you will need to do research to find out which components work well together, what kind of performance you can expect from disk controller x, y or z. But it is doable, many customers have already done this and it will allow you to design to your specific needs. Do note, you will need to configure it yourself and purchase licenses / support.

If you prefer a simpler approach, but still a certain level of flexibility then the “Virtual SAN Ready Node” approach is definitely a great option. It provides you a selection of around 40 different OEM configurations which have been validated by both the OEMs and VMware. Note though that these configurations are typically based on VM configuration profiles and IO profiles. This is mentioned in the Virtual SAN Ready Node list, there are low / medium / high configurations and also two different VDI configurations for each of the different server platforms. If you prefer a pre-validated solution, but need some flexibility then this is the way to go. Again, you will need to install/configure it yourself and purchase licenses / support, but it definitely easier than “component based”.

The third option is “VMware EVO:RAIL“. EVO:RAIL is at the far right of the slider –> Maximum Ease of Use. EVO:RAIL is pre-built on a qualified platform. This means that it comes pre-installed, and can be configured within 15 minutes. It has an easy / simple management interface that allows for easy patching/updating, simple VM creation and management, and even easier automatic scale-out (a couple of clicks). On top of that, it is sold as a single SKU (all licenses and support included) and all support will go through 1 channel. No more being pointed from one vendor to the other, no you contact that single vendor for both support of software as for hardware… Maximum Ease of Use as I said. If this is what you are looking for, EVO:RAIL is what you need.

As you see, when it comes to scale-out server SAN / hyper(visor) converged solutions… VMware offers you maximum choice.

Top 5 VMworld EMEA recommended deep dive geek sessions

I’ve been watching a bunch of the VMworld US session recordings. A couple of sessions were real gems and contain a lot of deep dive info, if you are a geek and like deep technical info make sure to register for the following sessions. These sessions are all by VMware employees who work on the actual product as a developer or technical product manager, so if you have a deep deep question don’t be afraid to ask.

Of course there are many many more deep dive sessions, but these are the ones I enjoyed watching and as my time is limited I may not have watched that one ultra deep geek tech session you presented. If you feel a deep dive session is missing. Please leave a comment!

last minute bonus, just watched this session and it was brilliant, especially for those interested in stretched clusters:

Virtual SAN / EVO:RAIL use cases versus supported

I have seen this being debated many times on twitter now, and I’ve seen various Virtual SAN (VSAN) and EVO:RAIL competitors use this in the past to mislead potential customers.

I think we have all seen these slides at VMworld or at a VMUG when it comes to VSAN or EVO:RAIL. The slide contains a couple of primary use cases:

evo:rail use cases

So what does that mean? Does this mean that VMware does not support Exchange or MS SQL on top of VSAN or EVO:RAIL? Does that mean that VMware does not support it as a DR target? Or what about a management cluster? Or what about running Oracle? Or maybe SAP? Or what about my WordPress instance? Or what about MySQL? Or although you mention VDI, would that only be VMware View? What about… Yes by now you get my drift.

Let me try to make it really simple: Primary use cases says nothing about support. Primary use case means that this where the vendor expects the product or solution to fit best. In this case it is where VMware expect VSAN/EVO:RAIL to fit best, this is the target market VMware will be going after with this release.

Why include this in a slide deck? Well it allows you (the user / consultant / architect) to quickly identify where the majority of opportunities will be with the current version for your environment or for your customers. It does NOT mean that if your use case, like running your Exchange environment for instance on top of VSAN, is not listed that it is not supported. (Try listing all use cases on a slide, it will get pretty lengthy.)

Running Tier-1 applications on top of VSAN (or EVO:RAIL) is fully supported as it stands today, however … your application requirements and your service level agreement will determine if EVO:RAIL or VSAN is a good fit. One example would for instance be that if your agreed SLA requires an RPO (recovery point objective) of zero then sync replication is the only option (or stretched clustering), now you will need to determine if this is possible with the platform you want to use (this goes for any solution!). (Yes, you can make that happen with the platform pretty soon before anyone wants to go there…)

I hope that clears things up a bit.

VMware EVO:RAIL use case: ROBO

Something that came up a couple of days back was a question around how VMware EVO:RAIL fits the ROBO (remote office branch office) use case. If you watched the demo you will have seen that it is very simple / easy to configure. It takes about 15 minutes to get you up and running and all you need to do is provide details like “IP ranges”, “Subnet mask”, “Gateway” and a couple of other globals.

This by itself makes EVO:RAIL a perfect solution for ROBO deployments… but there is more. When it comes to ROBO deployments and simplifying the roll out there are two more options:

  1. Provide configuration details during procurement process
  2. Specify configuration details in a file and insert in to appliance before shipment to remote office

evo:rail UI

I won’t discuss option 1 in-depth, as this will very much depend on how each of the EVO:RAIL Qualified Partners handles this on their website / during the procurement process. Basically what happens is that you provide your preferred server vendor with configuration details and they put it in to a file called “default-config-static.json” and this is injected in to the vCenter Server Appliance which also runs the EVO:RAIL engine. For the hackers who want to play around with EVO:RAIL, note that the location of the json file and the format may change with newer versions so make sure to always use the latest and greatest if you want to play around. If you have filled out these details, you can just click

Option 2 is also very interesting if you ask me. If you look at EVO:RAIL as it stands today, you have the option to upload a JSON file when you hit the configuration screen (as shown in the screenshot above). This JSON should contain all of your configuration details and then will allow you to configure EVO:RAIL with the click of a button. In other words, you ship the appliance to your remote office. You email them the JSON file (in a secured manner hopefully) and ask them to click “upload configuration file”. They upload the file and then run “Validate”, and probably fill out the password as you don’t want to sent that in clear text. That is it… Nice right :). Of course, if you want … you could even go as far as injecting the .json file into the vCenter Server Appliance yourself, but I am not sure if that will be supported.

As you can imagine, this greatly simplifies the deployment of EVO:RAIL as all it takes is just one click to configure, which is ideal for a ROBO scenario. Anyone can do it!