VMware vSphere Reviews

Recently I got some questions about this one. Who is better? Or who is cheaper?

I was worked in VMware and Microsoft, both covered virtualization products. Now, I’m working in one of Cloud Datacenter with many platform like Sun Solaris (Oracle), IBM AS400, IBM iSeries, IBM pSeries, Microsoft Hyper-V (the first Partner Hosted Productivity Cloud – PHPC in Asia), and VMware technologies (vSphere, vCloud and vCAC).

Based on that, don’t think too much about the platform. The most important is the SLA. All platforms is good as long as we manage the SLA. And use the most suitable platform for your applications. If you want to use Microsoft, then Windows Hyper-V 2012R2 is the right one. Don’t use any version below Windows 2012R2.

Anyway, back to the questions. Let’s make a simple requirement. This is roughly calculation.

Customer requirements:

They need to virtual all their infrastructure. 100 Physical Server with each servers have the specification: 2CPU, 8GB RAM, 100GB Disk. All Microsoft licenses are OEM.

Total Requirements:

• 100 x 2CPU = 200 pCPU
• 100 x 8GB RAM = 800GB RAM
• 100 x 100GB Disk = 10TB Disk
• 100 Windows Server 2012R2 Licenses
• Monitoring Tools required
• High Availability supported

Assumption:

CPU based (Option 1):

• Low CPU utilization, 10% average. 200 pCPU x 20% = 40 pCPU.
• Server configures with 2×6 Cores/CPU = 12 pCPU.
• Total server required based on CPU = 40 pCPU / 12 pCPU = 4 (Round Up).
• With N+1 roles (HA), then total servers: 4 + 1 = 5 Servers

RAM based (Option 2):

• RAM Utilized 80%. 800GB RAM x 80% = 640GB RAM
• Server configured with 128GB RAM. Maximum RAM utilized 80% then 128GB x 80% = 103GB (Round up)
• Total server required: 640GB RAM / 103GB RAM = 7 Servers (Round Up)
• With N+1 roles (HA), then total servers: 7 + 1 = 8 Servers
• For Microsoft Hyper-V, assumption required 2GB RAM for hypervisor. 128GB RAM – 2GB RAM = 126GB RAM x 80% = 101GB (Round Up). 640GB RAM/101GB RAM = 7 Servers. Total Server (N+1): 7+1 = 8 Servers

Because the application is highly memory consumption then we choice Option 2 (based on assumption and roughly calculation). I recommended to use the sizing calculator such as VMware Capacity Planning.

Licenses Required:

With Microsoft:

1. 8 x Windows Server Datacenter 2012R2
2. 8 x System Center 2012R2
3. 1 x Microsoft SQL Server 2012 STD Edition -> For DB

TOTAL: $78,994*

*Web Price (Y2014), excluded support and CALs for MSFT products

With VMware:

1. 16 x vSphere with Operations Management Enterprise Plus 5.5
2. 1 x vCenter Server Standard 5.5
3. 8 x Windows Server Datacenter 2012R2 -> For Guest OS
4. 1 x Microsoft SQL Server 2012 STD Edition -> For DB

TOTAL: $123,053*

*Pricelist (Y2014), excluded SnS and CALs for MSFT products

In the end, all is your choices. Enjoy.

VMware introduced replication in vSphere 5.5. The biggest limitation is that it only provides a single restore point only. This is an immediate show stopper for most customers. Multiple restore points are absolutely essential, because just like "good" data, any corruption/virus/dataloss from the source VM is immediately replicated to target VM, and if you don't spot the problem and perform failover to replica fast enough (before the next replication cycle) - which is going to be impossible in most cases - then you are done.

Other limitations
• No failback
• No traffic compression
• No traffic throttling
• No swap exclusion
• No network customization (network mapping)
• No re-IP upon failover
• Minimum possible RPO is 15 minutes
• Basic VSS quiescing (no application-aware processing)
• Works within single vCenter only
• No ability to create container-based jobs (explicit VM selection only)
• Limited seeding options: cannot seed from backup, or using different VM as a seed (disk IDs have to match)
• Different ports for initial and incremental sync required
• No good reporting

Also, be aware that biggest marketing push around vSphere replication is technically incorrect statement!
“Unlike other solutions, enabling vSphere replication on a VM does not impact I/O load, because it does not use VM snapshots”

It is simply impossible to transfer specific state of running VM without some sort of snapshot even in theory! In reality, during each replication cycle they do create hidden snapshot to keep the replicated state intact, just different type of snapshot (exact same concept as Veeam reversed incremental).

PROS: No commit required, snapshot is simply discarded after replication cycle completes.
CONS: While replication runs, there is 3x I/O per each modified block that belongs to the replicated state. This is the I/O impact that got lost in marketing.

Unlike VMware replication Veeam takes advantage of multiple restore points.
For every replica, Veeam Backup & Replication creates and maintains a configurable number of restore points. If the original VM fails for any reason, you can temporary or permanently fail over to a replica and restore critical services with minimum downtime. If the latest state of a replica is not usable (for example, if corrupted data was replicated from source to target), you can select previous restore point to fail over to. Veeam Backup & Replication utilizes VMware ESX snapshot capabilities to create and manage replica restore points.

Replication of VMware VMs works similarly to forward incremental backup. During the first run of a replication job, Veeam Backup & Replication copies the original VM running on the source host and creates its full replica on the target host. You can also seed this initial copy at the target site. Unlike backup files, replica virtual disks are stored uncompressed in their native format. All subsequent replication job runs are incremental (that is, Veeam Backup & Replication copies only those data blocks that have changed since the last replication cycle).

Conclusion:
Veeam Replication really stands out on top of the feature lacking VMware Replication. The numerous missing features like taking advantage of multiple snapshot replications, to help insure data integrity, no failback, no traffic throttling and no traffic compression etc., translate to only using VMware replication for simple use cases.

So it’s finally here!
The long-awaited release of vSphere 6.0, has been released, and will ready for download medio March we’ve been told. I’ve done a small write-up of some of the new features in this release.

Release cycles
As seen at VMworld, where many customers thought that VMware would release vSphere 6.0, VMware has adopted a strategy of longer release cycles of the core component vSphere. So instead of a yearly release we are most likely to see roughly 18 months release cycles instead. This is because the hypervisor needs to be stable all the time, and not something you’d need to upgrade all the time. On the other hand products like vRealize Operations or vRealize Automation Center will see shorter release cycles. I’m really liking this approach, as the hypervisor really is in the center of your data center core, and as such we need the absolute most stable product here.

Multi-processor Fault Tolerance
We’ve seen multiprocessor Fault Tolerance demoed at a few VMworlds so far, but now finally it’s here. with vSphere 6.0 you can now have Fault tolerance on VM’s with up to 4 vCPU’s. This finally opens up for the useful Fault Tolerance VM’s. I haven’t seen many critical VM’s with only 1 vCPU, even vCenter Server needs more than 1, so the use cases for the old Fault Tolerance were few and far apart.
A lot of older applications, haven’t been built with High Availability in mind and for this FT comes into play, and with the new 4 vCPU limit a lot more of older applications can be protected by FT as well. I’m guessing a lot of costumers will use this feature in their data centers. However the Bandwidth requirements for this will be quite steep, so cross data center FT might not be feasible just yet :). As with the old FT this won’t save you if your application corrupts, then both instances will be corrupt. For this you really need applications that were built for High Availability in mind.

Inter vCenter vMotion
This I think is one of the biggest new features of vSphere 6.0. The ability to vMotion between 2 vCenters is one thing a lot of people have been looking for, for a looong time. Moving VM’s without downtime to a new vCenter with newer vSphere, wasnt that easy if you deployed distributed switches. But now that really should be a thing of the past. A whole new set of design architectures should be set up now because of this feature.

Long distance vMotion
Another really nice new feature is long distance vMotion, where before you were limited to 5ms latency or 10ms in Enterprise+, you can now vMotion across links with up to 100ms of latency. For us Europeans that means we should vMotion vm’s across borders to neighboring countries or at last across the country. This opens up quite a few new scenarios for highly available infrastructure. In Denmark fx. we could vMotion between Seeland and Jutland, which would solve some of the Power issues we have :).

Web client
The last thing I will write about is the client. The new Webclient is much improved over the previous ones, and both looks and feels more like the C# client, which still is available in vSphere 6.0. Unfortunately its still not in HTML5, which would have been preferred, so the webclient could work on OS’s

Originally posted at vcdx133.com.

The amazing VMware vSphere 6.0 has just been announced and will be released in March 2015! Michael Webster wrote a great article about the significance of vSphere 6.0 that is worth reading. This a “brain-dump” of the impressive new features and improvements:

• Enhancement of vCenter Server architecture – SSO has evolved to the multi-service Platform Services Controller (SSO, Licencing, Certificate Authority, Certificate Store, Service Registration).
• vCenter Server Appliance – supports large (1000 hosts, 10,000 VMs) environments and Linked Mode
• Enhanced Linked Mode for vCenter – Microsoft ADAM has been replaced with a VMware “native Replication Technology” where vCSA is supported and Policies and Tags are also replicated.
• IP version 6 – Static IPv6, DHCPv6 with FQDN for 100% management of hosts and iSCSI, NFS, VMFS IPv6 support.
• Availability – Improvements to the Watchdog Remediation features of vCenter (SSO, vCenter, vCenter DB).
• Content Library – an Administrator’s multi-vCenter central repository for all VM Templates, ISO images, scripts and vApps.
• vSphere Client – is only used for direct connection to the ESXi host and for connecting to vSphere Update Manager, all other tasks must be performed with the vSphere Web Client.
• Enhanced vMotion – Cross vCenter vMotion supported and Long-Distance vMotion of up to 100ms RTT.
• vSphere Fault Tolerance supports 4 vCPUs and 64 GB RAM – with VADP support and any vDisk provisioning on different datastores.
• Increased Scalability – 64 Nodes per Cluster (incl. VSAN), 8,000 VMs per Cluster, 480 Logical CPUs per Host, 1,024 VMs per Host, 12TB RAM per Host.
• Virtual Data Center and Policy Based Management – Automates VM provisioning based on capacity and capability. Intelligently place VMs based upon policy. Monitor VM policy adherence with automated remediation. Automate initial VM placement without writing complex policies. Ongoing operational efficiencies via policy-based remediation throughout VM lifecycle.
• NFS Client version 4.1 with Kerberos – NFS benefits from Session Trunking and Multipathing, improved Security and improved Locking, Error Recovery and NFS Protocol efficiencies.
• Virtual SAN – All Flash datastore with SSD persistence. 2x more IOPS with VSAN Hybrid (up to 40K IOPS/host). 4x more IOPS with VSAN All-Flash (up to 100K IOPS/host). 64 Nodes per Cluster. 150 VMs/host (Hybrid), 200 VMs/host (All-Flash). VSAN Snapshots and Clones. H/W-based checksum and encryption support. Blade architectures supported (DAS JBOD). Rack awareness (tolerate rack failures). Flashing LEDs to detect failed disks.
• Virtual Volumes (VVols) with Storage Policy-Based Management (SPBM) – removes the need for management of LUNs and NFS volumes via enhanced VASA APIs. A single VVol is the equivalent of a VMDK file. Extends SDS control plane to monolithic storage.
• Storage I/O Control – Per VM reservations.
• Network I/O Control – Per VM and Distributed Switch bandwidth reservations.
• Support for FreeBSD 10.0, Asianux 4 SP3.
• Security Enhancements – Increased Flexibility of Lockdown mode, Added Smart Card Authentication to DCUI, Improved password and account management, Enhanced Auditability of ESXi admin actions, Added full certificate lifecycle management, Added certificate based guest authentication.

NOTE: This is based upon the information and features provided in the RC version of the vSphere 6.0 (Beta 2). There may be some differences between the features of the RC and GA versions.

Valuable Features:

Improvements to My Organization:

Room for Improvement:

Use of Solution:

Deployment Issues:

Stability Issues:

Scalability Issues:

Summary: The vSphere Webclient has been around since vSphere 5.0 but it’s fighting an uphill battle to gain user acceptance. I’ve recently tried using it as my primary administration tool with mixed success.

Recently I’ve been rebuilding my home lab to test out new features in vSphere6 among others. As VMware have been very vocal about moving to the webclient I thought it was about time I took the plunge and started using it in anger – after all it’s been out for several years and like many others until now I’ve stuck with the C# client. Unfortunately I can’t say it’s been an overly positive experience, largely because of browser compatibility issues rather the the design of the webclient itself. To be fair it does seem faster than in earlier releases. VMware KB2005083 lists the prerequisites for the WebClient (both server and client components) but it doesn’t detail the browser specific configuration you need to get it working successfully. This post will cover a bunch of settings you need to make but it’s largely for my own reference as I couldn’t find a single source of information elsewhere.

Browser and server tweaks to make it work

Surely one of the perks of a web based client is no client side setup right? Sadly no. I’m using a Windows 2012 server as my management station for my home lab, which isn’t representative of a real production environment as I’m less concerned with compliance, security etc. While mine is a niche use case some of the same settings apply to desktop Windows editions, especially Windows 8. There are a few configuration changes you need to make on Windows to allow you to work with vSphere via the web client;

• Enable desktop experience (instructions in VMware KB2054049) to allow Flash which is required by the web client (this is only required on Windows Server editions).
• Install the client integration plugin as Administrator, run IE as Administrator. Discussed in this forum post (and this one) though I’ve had mixed success getting it to work at all. Based on the fact that those two forums posts between them have over 50,000 views I’d say this is a very common issue and one that seems to vary with each browser.
• Disable Protected mode (internet and intranet zone) as per VMware’s advice. Obviously this reduces the security but if you’re choosing to use client applications on a server you’ve already made that choice!
• Install the root CA certificate (instructions here) to remove those annoying ‘this site is untrusted’ errors. Alternatively deploy certificates to replace the self-signed one’s that ship with vSphere, although that’s considerably more work!
• Disable pop-up blockers for the following sites;

I’m not sure if VMware publish a compatibility matrix across all their products but I’d suggest you have two different browsers installed so you can switch between them as required. For example IE is supposedly the fastest when using the webclient, but doesn’t work at all when trying to login to the Orchestrator configuration web service.

Tuning performance

Here are a few tips;

• Java heap tweaks are no longer required (unless you’re using NSX apparently – I’ve not tried it myself).
• Tweak Flash settings to allow more local storage
• Modify the web.properties file (just as I was finishing this post I found this Wikibooks entry which covers many of the configuration tweaks covered here. Who knew! Anyway I’m going to publish as I’ve written it now).
• If you’re working remotely be aware that the WebClient can be pretty bandwidth intensive. Use RDP if possible!

Let VMware know what you think

VMware are apparently listening to user feedback, according to this forum post, although in reality it’s largely an outlet for frustrated users!

Valuable Features:

Improvements to My Organization:

Use of Solution:

Deployment Issues:

Stability Issues:

Customer Service:

Initial Setup:

Implementation Team:

Cost and Licensing Advice:

Other Solutions Considered:

One of the major new features of vSphere 6 is the ability to vMotion over very long distances. With previous releases of vSphere the maximum network Round Trip Time (RTT) was 10 ms which equates to a distance of almost 400 miles. With Long-Distance vMotion the RTT has been increased to a whopping 100 ms which increases the distance to 4,000 miles – far enough to move a VM from London to New York.

Of course you do still require a L2 stretched network (L2 adjacency) which is where technologies like vSphere NSX come in, but what about the storage?

vSphere 5.1 introduced Enhanced vMotion which combined vMotion and Storage vMotion into a single operation so that shared storage was no longer required – essentially Long-Distance vMotion moves all of the storage for a given VM along with its memory.

This does not sound ideal as you would need to move an awful lot of data between London and New York – it is one thing to move a few GBs of RAM, but 100s of GBs of disk per VM is another matter. The answer to the problem is to combine Long-Distance vMotion with asynchronous storage array or vSphere replication.

For vSphere Replication this should be relatively straight forward as it is integrated into the hypervisor and it works at the VM level, storage array replication will be much more of a challenge as typically it replicates an entire datastore containing many VMs.

This is where Virtual Volumes comes in to play as they should allow replication to be controlled at the VM level. Long-Distance vMotion would need to synchronise the replication and switch the active site – sounds like a complex task, but it would bring tremendous advantages and make Disaster Avoidance available over almost any distance.

I am quite sure that this is something that VMware is currently working on with the likes of EMC and NetApp – so watch this space as hopefully Long-Distance vMotion is only going to get better.