vSphere, a feature overview

The software is based on three basic pillars, combined by a single slogan:

"Cut capital and operational costs over 50% for all applications (Efficiency) while automating quality of service (Control) and remaining independent of hardware, operating system, application stack, and service providers (Choice)."

As the efficiency claims will provide quite a challenge for VMware to overcome, let's have a look at the actual changes they have made to their existing software to achieve this goal.

 


This image depicts the general layout for vSphere: solidifying the Efficiency and Control pillars into three separate parts each: vCompute, vStorage, and vNetwork for Efficiency; Availability, Security, and Scalability for Control.

 

Until recently, the VMware Infrastructure Efficiency front was largely defined by three of its main features: CPU/Memory Optimization, Dynamic Resource Scheduling, and the VMFS. Each of these was able to provide a boost to performance by taking advantage of the entire virtual infrastructure. Through the combined improvements to vCompute, vStorage and vNetwork, VMware predicts a 30% increased consolidation ratio compared to the last version of VMware Infrastructure. We asked VMware about this, and heard the results were measured by using their very own VMmark, comparing ESX 3.5 and 4.0 on the same hardware platform. We believe the results to be generally realistic, but they should still be taken with a grain of salt.

Furthermore, VMware promises 50% more storage savings, thanks to vStorage Thin Provisioning and up to 20% additional power and cooling savings, thanks to Distributed Power Management that allows the data center to automatically VMotion VMs to as few physical machines as possible, allowing users to power down physical servers that are not needed at the moment.

Besides this, vSphere will offer more powerful virtual machines than before, allowing for:

 

  • 8 vCPUs per VM (up from 4)
  • 10 virtual NICs per VM
  • up to 255GB RAM per VM
  • 3 times more network throughput
  • a little over 200,000 IOPS maximum

 

When it comes out, a single vSphere deployment will be able to manage the following resources:

 

  • 32 physical servers with up to 2048 cores
  • 1280 virtual machines
  • 32TB of RAM
  • 16PB (petabytes - 1000TB) of storage
  • 8000 network ports

 

Keep in mind that it will be possible to cluster up to 10 vCenter Servers (vSphere's main management component).

On the Control side of things, vSphere makes managing this large amount of resources easy through the use of Host Profiles and the vNetwork Distributed Switch, which allows for comprehensive networking between all these virtual machines to be configured just as easily as in a "regular" data center. In fact, the Switch can actually be plugged into by vendors such as Cisco, so it can be configured in exactly the same way as a regular Cisco switch.

As mentioned before in one of our blogs, one-click configurable Fault Tolerance should keep important VMs safe from unexpected hardware failures, and storage-maintenance related downtime should be further minimized by introducing a feature called Storage VMotion. Remember the currently documented limitations of Fault Tolerance, however. It's High Availability, but only on the hardware-level, and will not account for software failures. Also, at this point, Fault Tolerance is limited to VMs with only a single vCPU, so although it's a very interesting feature, it leaves a lot of room for improvement.

Data Recovery is another nice little tidbit, which will essentially plug into your vSphere as a virtual appliance with a single purpose: one-click backup of any virtual machine, answering the first question asked by quite a few companies getting started with virtualization.

Lastly, vShield Zones is a self-learning, self-configuring firewall service, allowing users to set security policies to overall environments, enforcing the rules on an application level, and allowing them to travel along with the VM as it VMotions across the (internal or external) cloud.

For vSphere's last main pillar, VMware likes Choice (as long as they are included in whichever choice you end up making, naturally), and for that reason they proudly hold the claim that they are able to support any kind of server, any kind of storage, any kind of OS, any application, be they on premise or off premise. In the picture below, they compare their own supported OS list to that of Hyper-V.

 

 

On top of that, VMware has partnered up with several service providers (as linked before) to properly kick off their external cloud services with a large team of reliable players.

So what is VMware releasing? vSphere Pricing favors hex-cores
Comments Locked

11 Comments

View All Comments

  • Bandoleer - Wednesday, May 27, 2009 - link

    VMware has always stated that logical CPU's (HT) are not considered cores as licensing is concerned.
  • pcfxer - Sunday, April 26, 2009 - link

    e-mail, internet browsing sure, maybe even something like google docs, but running centralized applications is NOT nearly what management/marketing would have you believe it is.

    Any support technician that works with local and centralized application infrastructure (in the likes of Citrix/TSP) would agree with me immediately when I state - TSP is a bugger to debug and diagnose, the issues are complicated by odd application errors that don't relate to what is really happening. What really happens is that the NTUSER.DAT file becomes corrupt, why? (bad resource/data forking??) Not sure, myself, it's closed source on the TSP and on the centralized app (MS Word, etc.) ends.

    Centralized applications also require FAST and HIGH THROUGHPUT to work efficiently. Consider it like this: your computer stores the application so you optimize the HD latency, memory latency, cache latency etc. TSP however, relies on the network. for thin clients it's easy; just optimize the NIC and TCP/IP stack. Beyond that, it is BRUTAL! You start asking vendors how many simultaneous connections and the sustained latency/throughput with X number that they give you and you'll see the VERY puzzled looks on their faces.

    Do it anand, trust me, Cisco sent me to engineering to get the answers that I wanted. Some more expensive switches end up being SLOWER than others because of the latency incurred when using TSP with a larger number of clients.

    Main applications shouldn't be centralized, niche ones, maybe, but the most reliable deployment is a bunch of workstations running local applications. IT ALWAYS WILL! When was a data stream dropped between your hard drive? Does it happen? Yes, rarely. When do packets get dropped that are just as important? OFTEN.
  • has407 - Monday, April 27, 2009 - link

    Just because applications as architected and implemented today don't work well with a centralized/cloud model doesn't mean there's something wrong with the model, or a fundamental reason why applications--as in code that produces the same result--can't or won't behave reasonably with that model.

    We've been through a couple cycles of this, going back and forth between centralized and distributed. We had "cloud computing" (aka "service bureau's") decades ago, and they worked fine, because systems and applications were architected and implemented to work in that model. Ok, so they were green screens and not GUI's. So what? Then came the PC/client-server model, and now we appear to be moving back to the centralized/cloud model.

    The problems cloud/centralized models face today are a mirror image of the past (i.e., what happened in the 90's during the change from centralized to distributed and client-server). The problems are transitional, and are largely the result of attempting to make applications built for one model behave properly in this (*cough*) "new" (*cough*) model. Been there, done that, and we'll do it again. *yawn*

    The only thing that seemingly hasn't changed in decades is people who insist "X" won't work because, by darn, "X" is what they know and because they're narrowly focused on one part of the picture.
  • Milleman - Sunday, April 26, 2009 - link

    Why aren't they supporting the Ubuntu 8.04 LTS version? Very strange, since datacenters or providers really wants to stay supported on OS version as long as possible.
  • has407 - Sunday, April 26, 2009 - link

    They support 8.04, 7.04 and quite a few others; see:
    http://www.vmware.com/pdf/GuestOS_guide.pdf">http://www.vmware.com/pdf/GuestOS_guide.pdf
  • has407 - Wednesday, April 22, 2009 - link

    > Another question left unanswered is whether VMware would allow for quad-socket machines in the Essentials packages...

    They're pretty clear about that, per the VMWare vSphere 4 Pricing, Packaging and Licensing Overview: "[Essentials and Essentials Plus] include licenses for three physical servers (up to two processors each)...". However, it's unclear whether they'll allow a max of 6 processors in any combination up to 3 boxes; e.g., 4+2 or 4+1+1, but few people are likely to looking for those in combination with Essentials (that 4x box is an expensive outlier).


    > For the Essentials Plus, Advanced, and Enterprise Plus packages, the maximum number of physical cores per CPU is upped to 12...

    You don't get that with Essentials Plus; the 6-core/proc limit still holds.
  • LizVD - Thursday, April 23, 2009 - link

    After some digging around on VMware's website, I ran into this:

    "Each physical server may contain up to two physical processors with up to 6 cores per processor."

    on the following page: http://www.vmware.com/products/vsphere/buy/overvie...">http://www.vmware.com/products/vsphere/...re%20pri...

    So I guess that's cleared up now. :)
  • LizVD - Thursday, April 23, 2009 - link

    Thanks for the heads up on this, we based our questions on the documents we received from VMware prior to the press release. As it turns out, those were not very clear on certain numbers and outright wrong on others (as noted in the picture on page 4)

    Now that the information has been released publicly, I'll get right to correcting these things.
  • has407 - Wednesday, April 22, 2009 - link

    > ...otherwise roughly translate to a slightly less than full-featured Standard version (only works on ESXi)...

    Not sure what you mean by "only works on ESXi"? The choice of ESX or ESXi is the same for all editions and is a "deployment-time choice". Or are you referring to specific features that will only work with ESXi? If so, can you be more specific? Thanks.
  • blyndy - Wednesday, April 22, 2009 - link

    "...a fracture of their capacity..." ...?

Log in

Don't have an account? Sign up now