Home > Blogs > VMware vSphere Blog > Category Archives: vSphere

Category Archives: vSphere

VMware Virtual SAN and ScaleIO : Fundamentally Two different approaches to Software-Defined Storage

There’ s a lot of buzz and excitement around Software-Defined Storage (SDS) and hyper-converged storage solutions.  Particularly around VMware’s recently introduced product: VMware Virtual SAN.

VMware Virtual SAN is seeing tremendous traction in the market since its release. After only two full quarters of availability, we already have many hundreds of customers happily running a variety of applications on Virtual SAN, from VDI to test & development  to production applications and databases.  Virtual SAN customers love the product’s simplicity and integration with the VMware stack.

But along with increased awareness and traction, we are also seeing an increasing level of confusion in the market on the key differences between Virtual SAN and other SDS products.  Particularly, we have been receiving a great deal of questions from our customers and partners about differences between Virtual SAN and EMC ScaleIO. They are asking us about where Virtual SAN should be used, where ScaleIO should be used, and whether there’s any real difference between the two.

This type of confusion is unfortunate because VMware Virtual SAN and ScaleIO follow two fundamentally different approaches to SDS.

  • VMware Virtual SAN is designed specifically around tight integration with vSphere – with the objective of providing super-simple management and very high levels of performance for vSphere VMs.  Virtual SAN is always deployed in a hyper-converged configuration, where storage is converged with the vSphere compute nodes. Virtual SAN is targeted at the generalist IT professional, not just storage experts.
  • ScaleIO has a different design point – to provide highly scalable server-based storage for heterogeneous platforms, including multiple hypervisors and physical servers. ScaleIO has its own installation, configuration and management workflows which are typically driven by expert storage administrators.

The confusion between VMware Virtual SAN and ScaleIO is partially fueled by recent press articles, which claim full integration of ScaleIO into vSphere’s ESX kernel.  This claim is not accurate. There are no plans to port the core ScaleIO product in the ESX kernel or integrate it with the rest of the vSphere stack.

More specifically, ScaleIO consist of two  components: a) a block storage server that is the core of the ScaleIO product and which serves block storage to its clients through the ScaleIO protocol; b) a client which connects to the server and allows VMs and applications to access storage on ScaleIO clusters. This model is very similar to an iSCSI target server serving data to iSCSI initiators. EMC has written an ESX kernel driver that implements a ScaleIO client module. It ‘talks’ the ScaleIO protocol and accesses the ScaleIO server(s). It exposes storage to VMs running in vSphere in a way similar to iSCSI volumes. This ScaleIO driver has been written using  public kernel APIs that are available to any VMware partner who develops kernel drivers in ESX. The ScaleIO server is not being ported in or integrated with vSphere and the ESX kernel. The ScaleIO server runs on Linux servers, either on bare metal or as a virtual appliance.

This architectural model allows ScaleIO to be a great SDS solution for heterogeneous platforms.

In the case of bare metal deployments VM I/O goes through the in-kernel driver and onto the external ScaleIO cluster over an IP network as it is the case with other storage arrays. In the virtual appliance case, a VM I/O operation traverses the ESX storage stack through the virtual appliance.

In contrast, VSAN and all its components are natively integrated with vSphere. The key functional components of VSAN, including its “server” functionality, run in the ESX kernel. This fundamental difference in architecture allows VSAN to be optimized for vSphere VMs in an unparalleled way.  VSAN is also integrated directly with the ESX control plane, vCenter  and vSphere APIs to provide a simple and effective management experience.  Together, these integrations provide important benefits to vSphere customers:

  • Performance and Overhead: The full kernel integration gives VMware Virtual SAN higher levels of performance and efficiency because Virtual SAN can more efficiently utilize the available memory and CPU cycles. Hence, Virtual SAN’s memory footprint and CPU cycles consumed per operation are the lowest in the market. Furthermore, compute and storage operations are executing inside the same layer of software, minimizing communication latencies.  This efficiency translates to  more compelling performance and total-cost-of-ownership  for the end user[V3] . By contrast, no other hyper-converged solution has its “server” logic integrated in the vSphere kernel, limiting the gains and efficiencies that can be achieved by these solutions.
  • Management integration: Virtual SAN is designed to be managed through vCenter, by any administrator who is familiar with vSphere.  The setup, configuration and ongoing management of the product are simple and  fully integrated with vSphere management workflows.  As a result, there are no separate management consoles and solutions. The required storage properties of each VM and virtual disk are expressed in the form of policies.  Effectively, storage becomes a quality of every VM, not a separate function.
  • Programmatic APIs: The functionality of Virtual SAN’s control plane is exposed through new or extensions to existing vSphere APIs. These are stable APIs with s wide range of language bindings that VMware customers have been using for years to automate their operational processes.
  • vSphere Features: In addition, since Virtual SAN is embedded within the hypervisor, all vSphere features such as DRS, vMotion, SVMotion, High Availability, vSphere Replication, and others are seamlessly supported with VSAN.

VMware Virtual SAN’s architectural model allows it to be the best storage solution for hyper-converged vSphere environments and for vSphere VMs. It does not address non-vSphere storage needs today.

So what does it mean in terms of where each solution should be used? In practice things are never black or white as we would like them to be, but at a high level there are some key aspects that we can keep in mind when comparing:

  • Use VMware Virtual SAN if you value deep integration with vSphere, both on the data path and control plane. Virtual SAN is deployed in a hyper-converged model, where storage is converged with compute on the same x86 hosts and storage scales in alignment with vSphere clusters (up to 32 nodes per cluster today, soon to become 64). We believe the Virtual SAN approach delivers highly differentiated, unique advantages for customers of all sizes looking for an SDS solution for vSphere.
  • Use ScaleIO when delivering highly scalable shared storage from a single storage pool to different hypervisors or across multiple vSphere clusters. The primary use case for ScaleIO is serving storage for a heterogeneous environment (i.e when storage is served to a diverse set of hypervisor clients or between virtual and physical environments) or when the storage system needs to scale beyond the size of a vSphere cluster.

The picture below should help clarify what these two products are positioned for:

VSAN                ScaleIO


VMware’s vSphere Big Data Extensions (BDE) achieves Hortonworks Operations Ready Certification


Hortonworks announced on the 17th December 2014 that VMware’s Big Data Extensions tool for Hadoop on virtual machines is now both HDP Certified and Operations Ready. HDP is the Hortonworks Data Platform – an open Hadoop platform that is centered on YARN. The Operations Ready designation is a new certification introduced by Hortonworks to focus attention on those tools that integrate in an approved way with Apache Ambari by making use of the open Ambari management application programming interfaces. The focus of the program is to certify operational tools for managing a Hadoop/HDP cluster. The Operations Ready program also provides assurance to enterprises adopting Hadoop that the tools they select to run and interact with Hadoop have been tested and validated to work correctly. At VMware we are excited to get this additional level of certification for VMware’s BDE and we look forward to continued engineering collaboration with Hortonworks.

Here is the description of the new Operations Ready program from Hortonworks:


You probably by now have also seen the recent VMware Big Data Extensions 2.1 announcements. Here is a quick summary of those new features in 2.1:


BDE 2.1 was announced as being Generally Available in October 2014. One of the central new features in BDE 2.1 is better integration with the de-facto Hadoop management tools from the distro vendors. Chief among those tools is Ambari. This integration with Ambari was the result of a request made to us directly by the VMware BDE user community.

BDE 2.1, with the new application manager construct, can now use the Ambari APIs under the covers to provision the HDP software into the virtual machines that it has created through cloning its template virtual machine. This method of deploying everything through BDE ensures that the resulting new Hadoop cluster is entirely compatible with Ambari. That is important because many of our users would like to use Ambari and VMware vCenter together from the point at which a cluster is provisioned onwards.

  • Ambari is the management tool of choice among HDP users in order to gain insight into what is going on at runtime at the Hadoop level (e.g. checking the status of HDFS, YARN, MapReduce and other services) and to make service changes there.
  • VMware vCenter is the virtualization infrastructure management tool that is in use at tens of thousands of VMware’s customers to view system behavior and performance at the virtual infrastructure level (virtual machines, physical machines, consumed resources and performance data). vCenter with the BDE plug-in is in popular use for deploying user Hadoop clusters today at many enterprises.

The BDE plug-in uses the vCenter APIs as well as the Ambari Blueprint APIs. Combining the two tools together to collaborate on the Hadoop provisioning details simplifies the management of your virtualized Hadoop cluster significantly. Both the Hadoop application architect and the virtualization manager can converse about the components of the HDP cluster and their effect on hardware consumption.

Hortonworks’ new Operations Ready program is one of a set of certifications that are currently available from the company. Other certifications available are the YARN Ready, Security Ready and Governance Ready programs. You can read more about the new programs here:  http://hortonworks.com/blog/accelerating-adoption-enterprise-hadoop

You can find the full BDE Administrator’s  and User’s  Guide and the BDE Command Line Interface Guide, as well as the Release Notes at: https://www.vmware.com/support/pubs/vsphere-big-data-extensions-pubs.html


Operationalizing VMware Virtual SAN: Automating vCenter Alarm Configuration Using PowerCLI

powercli 5.8 icon

Welcome to the next installment in our Operationalizing VMware Virtual SAN series. In our previous article we detailed “How to configure vCenter alarms for Virtual SAN”. In today’s article we will demonstrate how to automate that configuration workflow leveraging PowerCLI.

(Many thanks to VMware genius Alan Renouf (@alanrenouf) for his contributions to this topic) [Joe Cook: @CloudAnimal]

The PowerCLI code required to automate the configuration of vCenter Alarms for Virtual SAN is considerably straightforward.

1. Connect to vCenter

Connect-VIServer -Server -User Administrator@vsphere.local -Password vmware

2. Define the the Virtual SAN cluster where you would like the rules to be created

$Cluster = "Cluster Site A"

3. Next we create a hash table with the desired VMware ESXi Observeration IDs (VOB IDs) for Virtual SAN and include a description for each VOB ID.

If you are not used to programming, the concept of arrays and hash tables may be a bit confusing. Using variables is generally much easier to understand. One way of understanding variables is to think of them simply as a short amount of text used to represent a larger amount of text in your program or script ($x=”larger amount of text”). Instead of typing “larger amount of text” continually, you can simply type $x and the language interpreter (in our case PowerShell), will substitute the string “larger amount of text” wherever it finds $x in your script. Variables can be used to greatly reduce the amount of code you have to type, make your scripts much easier to read, and have many other uses as well.

If we think of variables as ways to store one value to reference, we can think of arrays as a way to store multiple values to reference. In our example today, we would have to create at least 32 variables to perform the same work that we can with one hash table.

A hash table is a type of array that is also known as a dictionary. It is a collection of name-value pairs (e.g. “name”=”value”) that can be used . Here we have an example of a basic hash table:

$HashTableName = @{
VOB_ID_A="VOB Description";
VOB_ID_B="VOB Description";
VOB_ID_C="VOB Description";

In the table below we have a breakdown of the components of the code used to create a hash table:

Syntax Component Description
$HashTableName = Replace “HashTableName” with the text you wish to use to reference this list of key-values pairs.
@{ Indicates the start of the hash table or array
VOB_ID_A=”VOB Description”; Key-Value pair to store within the hash table. VOB_ID_A will be the VOB ID from the VMware ESXi Observation Log (VOBD) (e.g. “esx.audit.vsan.clustering.enabled”). “VOB Description” will be the description of the associated “VOB ID” (e.g. “Virtual SAN clustering service had been enabled”). Make sure to use quotation marks whenever spaces are used and to separate each key-value pair with a semicolon (;).Examine /var/log/vobd.log on your vSphere host to obtain possible VOB IDs. See here for a list of VMware ESXi Observation IDs for Virtual SAN.
} Indicates the end of the hash table or array

Here is an example of a hash table with a single key-value pair representing a single vCenter Alarm for Virtual SAN:

$VSANAlerts = @{
"esx.audit.vsan.clustering.enabled" = "Virtual SAN clustering service had been enabled";

Below is the actual hash table that we will use in our example Virtual SAN Alarm Configuration script. It is fully populated with all of the recommended VOB IDs for Virtual SAN along with the description for each. We have labeled this hash table as “$VSANAlerts”. You will see $VSANAlerts referenced further along in the script as we reference the items within our hash table.

$VSANAlerts = @{
 "esx.audit.vsan.clustering.enabled" = "Virtual SAN clustering service had been enabled";
 "esx.clear.vob.vsan.pdl.online" = "Virtual SAN device has come online.";
 "esx.clear.vsan.clustering.enabled" = "Virtual SAN clustering services have now been enabled.";
 "esx.clear.vsan.vsan.network.available" = "Virtual SAN now has at least one active network configuration.";
 "esx.clear.vsan.vsan.vmknic.ready" = "A previously reported vmknic now has a valid IP.";
 "esx.problem.vob.vsan.lsom.componentthreshold" = "Virtual SAN Node: Near node component count limit.";
 "esx.problem.vob.vsan.lsom.diskerror" = "Virtual SAN device is under permanent error.";
 "esx.problem.vob.vsan.lsom.diskgrouplimit" = "Failed to create a new disk group.";
 "esx.problem.vob.vsan.lsom.disklimit" = "Failed to add disk to disk group.";
 "esx.problem.vob.vsan.pdl.offline" = "Virtual SAN device has gone offline.";
 "esx.problem.vsan.clustering.disabled" = "Virtual SAN clustering services have been disabled.";
 "esx.problem.vsan.lsom.congestionthreshold" = "Virtual SAN device Memory/SSD congestion has changed.";
 "esx.problem.vsan.net.not.ready" = "A vmknic added to Virtual SAN network config doesn't have valid IP.";
 "esx.problem.vsan.net.redundancy.lost" = "Virtual SAN doesn't haven any redundancy in its network configuration.";
 "esx.problem.vsan.net.redundancy.reduced" = "Virtual SAN is operating on reduced network redundancy.";
 "esx.problem.vsan.no.network.connectivity" = "Virtual SAN doesn't have any networking configuration for use."

(For more information on working with PowerShell hash tables, see this handy Microsoft TechNet article)

4. Next we use the Get-View cmdlet to query the vCenter Alarm Manager for each VOB ID listed in step 3.

The Get-View cmdlet returns the vSphere inventory objects (VIObject) that correspond to the specified search criteria.

$alarmMgr = Get-View AlarmManager
 $entity = Get-Cluster $Cluster | Get-View
 $VSANAlerts.Keys | Foreach {
 $Name = $VSANAlerts.Get_Item($_)
 $Value = $_

5. Create the vCenter Alarm specification object

 $alarm = New-Object VMware.Vim.AlarmSpec
 $alarm.Name = $Name
 $alarm.Description = $Name
 $alarm.Enabled = $TRUE
 $expression = New-Object VMware.Vim.EventAlarmExpression
 $expression.EventType = Vim.Event.EventEx
 $expression.eventTypeId = $Value
 $expression.objectType = "HostSystem"
 $expression.status = "red"
 $alarm.expression = New-Object VMware.Vim.OrAlarmExpression
 $alarm.expression.expression += $expression
 $alarm.setting = New-Object VMware.Vim.AlarmSetting
 $alarm.setting.reportingFrequency = 0
 $alarm.setting.toleranceRange = 0

6. Create the vCenter Alarm in vCenter

 Write-Host "Creating Alarm on $Cluster for $Name"
 $CreatedAlarm = $alarmMgr.CreateAlarm($entity.MoRef, $alarm)
 Write-Host "All Alarms Added to $Cluster"

As you can see, the steps to create vCenter Alarms for Virtual SAN are actually pretty straightforward. If you have not yet began monitoring your Virtual SAN environment, these steps can accelerate the process quite rapidly and you really do not have to be an expert in PowerCLI to do so.

VMware Hands on Labs

Here is a great tip brought to you by our friends at the VMware Hands on Labs. If you would like an excellent shortcut to getting “hands on” creating vCenter Alarms for Virtual SAN, using PowerCLI cmdlets, try out the lab below:

HOL-SDC-1427 – VMware Software Defined Storage: Module 5: Advanced Software Defined Storage With SPBM and PowerCLI (30 minutes)


We have many more articles on there way so share, re-tweet, or whatever your favorite social media method is. You will not want to miss these!

(Thanks to @millardjk for his keen eye)



Reference Architecture for building a VMware Software–Defined Datacenter

The latest in our series of reference architectures is now available. This is an update to the previous version which brings in additional products and covers the vCloud Suite 5.8 release.

This reference architecture describes an implementation of a software-defined data center (SDDC) using VMware vCloud® Suite Enterprise 5.8, VMware NSX™ for vSphere® 6.1, VMware IT Business Management Suite™ Standard Edition 1.1, and VMware vCenter™ Log Insight™ 2.0 to create an SDDC. This SDDC implementation is based on real-world scenarios, user workloads, and infrastructure system configurations. The configuration uses industry-standard servers, IP-based storage, and 10-Gigabit Ethernet (10GbE) networking to support a scalable and redundant architecture.

Continue reading

Infographic – Walk Through of VMware Availability

Here’s a visualization we put together to help people understand the various offerings from VMware that can positively affect your levels of availability.

Hope you like it!

VMware-Availability  <click here for pdf>

IOUG Survey Webcast Replay Site

The permanent home for the IOUG “Oracle on vSphere” survey webcast is listed below along with the actual survey itself. The “Oracle on vSphere” VMware press book link is also listed.

IOUG Survey


IOUG Survey Webcast


IOUG Survey blogs


The official VMware press book and the definitive authority on the subject of Oracle on vSphere:


VMware Configuration Guide for Virtual SAN HCL Component Updates

The Virtual SAN Configuration Guide has been updated with new components. We recently certified 12 SSDs, updated 4 existing SSD certifications, and updated firmware information for 2 HDDs. Make sure to visit the VMware Configuration Guide for Virtual SAN for more details!

Here is a list of changes:

New SSDs
•  NEC S3700 400GB SATA 2.5 MLC RPQ
•  NEC N8150-712

Updated SSD Certifications
• Samsung SM1625 800GB SAS SSD1
• Cisco UCS-SD800G0KS2-EP
• EMC XtremSF1400 PCIEHHM-1400M
• EMC XtremSF700 PCIEHHM-700M

Updated Diskful Writes per Day (DWPD) for Samsung and Cisco drives
A new firmware, B210.06.04, was certified for EMC PCI-E SSDs

HDD Firmware Information Updates
•  Fujitsu HD SAS 6G 1.2TB 10K HOT PL 2.5” EP
•  Hitachi 6Gbps,900GB,10000r/min,2.5in.


VMworld US 2014 in San Fransisco Panel Discussion “Applications on Oracle on vSphere” Panel

Mike Adams and Don Sullivan conducted a panel discussion at VMworld in San Francisco in August which highlighted a group of very successful VMware customers. The panelists answered questions pertaining to their varied application implementations running on Oracle on vSphere.  Their applications stories varied from SAP to Homegrown travel applications and from Oracle Identity Management to a broad sampling of Higher Education Applications.  The commonality was that they were all spectacularly successful.

Dan Young represented Indiana University when receiving the “VMware Innovation Award” rushed over from the Marriott Marquis to join the panel and highlighted the day with entertaining commentary of how he was sitting on the panel and receiving the award the same week that 128,000 Indiana University students were registering for classes.   He explained to the crowd how the virtualized database services model and the stability that the architecture provided was responsible for affording him this opportunity.  Jon Tucker from First National Bank of Nebraska in Omaha talked glowingly of the success of the bank’s Oracle Identity Management system and Kris Cook of SITA described how virtualization enhanced their homegrown travel applications environment.  Finally Mike Peter’s of Conagra got a big laugh when he described how their 20vCPU virtualized SAP Supply Chain system running on an Oracle DB was responsible for delivering all the frozen foods that the audience might consume that evening.

Each of these customers brings a unique experience with a common story.  “This is my application and it is very important and it runs better because it runs on vSphere”

For the first time VMware also conducted an Oracle customer panel at VMworld Europe in Barcelona but no video was produced of that event.  The event in Europe featured Eric Mealy CIO or Societe Generale bank of Luxembourg and Tobias Appelo of Cap Gemini who discussed their implementation at Centrica Energy in the UK.

Below is the YouTube link for the video from the San Francisco event.

VMworld US (SF) 2014 – Applications on Oracle on vSphere Customer Success Stories (Conagra, SITA, IU, FBNO)


Operationalizing VMware Virtual SAN: Configuring vCenter Alarms

VMware Virtual SAN has received amazing response from the virtualization community. Now as more and more customers are completing the acquisition and implementation processes, we are receiving more requests for operational guidance. Day 2 operations is perhaps my favorite topic to explore. Essentially the questions asked can be summed up as “Ok, I have done the research, proved the concept, and now have this great new product. Help me know the recommended practices to monitor, manage, and troubleshoot the inevitable issues that pop up with any software”. This question is the driver behind our new blog series, “Operationalizing VMware Virtual SAN“.

In this series, our aim is to take your most frequently asked questions around Virtual SAN Operations and provide detailed recommendations and guidance. In our first article in this series we look to answer the question “How do I configure vCenter Alarms for Virtual SAN?

(Many thanks to William Lam (@vGhetto), Christian Dickmann (@cdickmann), Rawlinson Rivera (@PunchingClouds), and Ken Werneburg (@vmKen) for their much appreciated interest and contribution to this series): [Joe Cook: @CloudAnimal]

Continue reading

SAP SD Benchmark Results on vSphere Shows Near Native Performance

I wanted to highlight some recent work done using a 3rd party benchmark and audited certification process that helps to address concerns that virtual overhead is still unacceptable for enterprise applications.

Many of our customers are no longer focused on this negligible consumption by virtualization as VMware software defined infrastructures have continued to demonstrate they can meet all their application needs, but yet some people still ask for this information.

SAP provides a test and certification methodology known as the Sales and Distribution (SD) Benchmark which provides several units of measurement, including Users and SAPS, that determines a hardware-independent score. This benchmark is run on both virtual and physical platforms and is well scrutinized before a certification number is issued.

There are two results I’d like to draw attention to:

  • Certification Number 2014043 (11/7/2014) by Dell/VMware – 9400 Users, 51400 SAPS
  • Certification number 2014017 (5/5/2014) by Dell – 10,253 Users, 55970 SAPS

These two benchmarks were performed on the exact same hardware and application stacks with the only exception being that VMware ESXi 5.5 was used on the most recent test. From this we can easily demonstrate that this comprehensive application and database benchmark shows only a 8.3% difference in virtual versus physical performance.

Additionally it’s worth noting, for Monster VM fans, that the virtual machine was configured with 48x vCPU’s and 256GB of RAM.

The message here is that virtual performance of an enterprise’s most demanding applications is near that of physical and that the value provided from the virtual platform more than exceeds the minute cost. Be confident – virtualize everything!

Special thanks to our partner Dell and our performance gurus (Erik, Sebastian & Louis) at VMware for these efforts.