What is the Upside to VMware to the SMB?
-
@markds said:
@scottalanmiller One common case we saw back then was virtualising Exchange servers. For some reason there was a very noticeable degradation in disk performance. Something that is likely to have improved since then.
I'm guessing older Exchange. Exchange changed how it accessed the disks in the last few years and it doesn't have the disk issues that it used to have.
-
@markds said:
We also found that Xen didn't perform well when overcommitting memory. From memory (no pun intended) VMware does page deduplication and compression when available memory gets low.
This meant we could push contention ratios far more which made up for the cost of a license. I think in the SMB area this would be true as $500 is going to be cheaper than buying an additional host (let alone the running cost).
VMware definitely handles memory compression and dedupe way better than anyone else. Although it wouldn't be $500 versus another node, it would be $500 versus the cost of more memory in most cases. Not that that buys you loads of memory, but it does buy some.
-
Xen has memory dedupe in the hypervisor. The place where it has issues is in the PV drivers. They have limited support there.
-
@scottalanmiller said:
Funny, when we first tested VMware, Xen was so much faster than it literally came down to one being able to run workloads and one not, on the same hardware. Because we did virtualized PBXs, Xen was the only option as VMware simply wasn't fast enough for audio processing.
We do a lot of voice stuff and whilst our termination gear is not virtualised, most of our customers who do choose to virtualise their endpoints are using VMware. They don't have problems once we tell VMware to reserve resources for that VM. The customers that do have problems are those who virtualise onto EC2, but thats a totally different issue.
I think biggest issue with VMware is the looming threat of licensing costs. $500 is not much even for SMBs and esp compared to labour costs. However, there is going to come a time as the business grows that its going to need more than 3 hosts, want high availability and converged storage. That jump is not linear with VMware and in some cases I can see it being cheaper to migrate away from VMware at that stage, esp with the pricing from hyperconverged vendors starting to become more reasonable.
Speaking of, did you calculate the effective cost of your Scale licensing ie price from Scale - effective cost of Dell hardware etc?
-
@markds said:
Speaking of, did you calculate the effective cost of your Scale licensing ie price from Scale - effective cost of Dell hardware etc?
I have not, that would be an interesting study to do. It's a little difficult as it wouldn't be licensing, but support. But if you lump the two together for a general comparison it would be meaningful.
-
@markds said:
We do a lot of voice stuff and whilst our termination gear is not virtualised, most of our customers who do choose to virtualise their endpoints are using VMware. They don't have problems once we tell VMware to reserve resources for that VM. The customers that do have problems are those who virtualise onto EC2, but thats a totally different issue.
Issues on EC2? We do a lot of telephony on Rackspace, which is Xen with OpenStack, and haven't had issues for years, not even before they were open stack. I'm very surprised that EC2 isn't as good or better.
VMware definitely can handle audio processing now. This was ~2003 when they were lagging behind. I know that by 2006 they still weren't handling it well. But that's when we stopped looking at them for several years. We moved to them, I want to guess, around 2009 and by that time telephony was fine. They had advanced a lot in the interim.
-
@scottalanmiller said:
I have not, that would be an interesting study to do. It's a little difficult as it wouldn't be licensing, but support. But if you lump the two together for a general comparison it would be meaningful.
Indeed. When I first looked at Nutanix I was shocked at the pricing, that was until I subtracted hardware & labor (install and migration). We didn't end up proceeding with Nutanix due to concerns over their closed review policies and lack of guarantees on performance.
Scale pricing would be extra interesting seeing that you would also exclude hypervisor pricing as well as (I think it uses KVM internally?)
-
@markds said:
Indeed. When I first looked at Nutanix I was shocked at the pricing, that was until I subtracted hardware & labor (install and migration). We didn't end up proceeding with Nutanix due to concerns over their closed review policies and lack of guarantees on performance.
Yeah, Nutanix burned a lot of bridges permanently with that stuff. Once you know that they are faking their reviews and data there is no way you want to do business with them. Just way too much to go wrong. I've even had a little pressure put on from them to back off on disclosing that to people and I've never done business with them (nor would I.)
-
@markds said:
Scale pricing would be extra interesting seeing that you would also exclude hypervisor pricing as well as (I think it uses KVM internally?)
That's correct, it is KVM.
-
@scottalanmiller said:
Issues on EC2? We do a lot of telephony on Rackspace, which is Xen with OpenStack, and haven't had issues for years, not even before they were open stack. I'm very surprised that EC2 isn't as good or better.
There are some inherent issues with EC2 but they rarely cause issues with SMB customers. The real issue with EC2 is the elasticity it offers customers. There have been numerous times customers have had a cloud consultant downsize their pbx instance to save a few dollars, only for it to cause issues later on. At least with on-premises virtualisation resources don't change that often.
-
@markds said:
@scottalanmiller said:
Issues on EC2? We do a lot of telephony on Rackspace, which is Xen with OpenStack, and haven't had issues for years, not even before they were open stack. I'm very surprised that EC2 isn't as good or better.
There are some inherent issues with EC2 but they rarely cause issues with SMB customers. The real issue with EC2 is the elasticity it offers customers. There have been numerous times customers have had a cloud consultant downsize their pbx instance to save a few dollars, only for it to cause issues later on. At least with on-premises virtualisation resources don't change that often.
A "cloud consultant"? Where does that person come from?
The elasticity of EC2 is supposed to be in spinning up other VMs, not constantly resizing existing ones.
-
@scottalanmiller said:
A "cloud consultant"? Where does that person come from?
The cloud naturally <grin>. In essence its usually a potential MSP doing an audit and offering to save the customer $x.
The elasticity of EC2 is supposed to be in spinning up other VMs, not constantly resizing existing ones.
Agreed, but Amazon's online advisor tool, makes it too easy for people without proper understanding to perform actions. That being said the ability to terminate a VM, reattach the ESB to a new instance and spin up is quiet useful. If only Amazon would allow you to annotate an instance with "requires min 2 cores, 2gb ram"
-
@markds said:
@scottalanmiller said:
A "cloud consultant"? Where does that person come from?
The cloud naturally <grin>. In essence its usually a potential MSP doing an audit and offering to save the customer $x.Ah. So not an EC2 issue, a company doing foolish things and/or hiring someone who doesn't know what they are doing to do foolish things. They might do the same thing on local resources too.
I thought that this was some kind of automated, Amazon provided tool that I did not know about
-
@markds said:
Agreed, but Amazon's online advisor tool, makes it too easy for people without proper understanding to perform actions. That being said the ability to terminate a VM, reattach the ESB to a new instance and spin up is quiet useful. If only Amazon would allow you to annotate an instance with "requires min 2 cores, 2gb ram"
I have all that power to be foolish with local resources, too. And I use it often. We tune memory very tightly, for example, just because we can.
-
@scottalanmiller said:
I thought that this was some kind of automated, Amazon provided tool that I did not know about
Just Trusted Advisor and the wrong people using it
https://aws.amazon.com/premiumsupport/trustedadvisor/ -
The "wrong people" being the key issue. Any top command will cause the same issues to happen even on physical hardware.
-
@scottalanmiller Just thought of another upside. I think ESXi manages swapping better. Every vm has a preallocated swap file at the hypervisor level equal to its assigned memory. Meaning if you overcommit memory, and you run out of host memory you will begin to swap at the hypervisor level . The virtual machine doesn't know a swap file is being used and just the memory access suddenly got slow (ie true memory virtualisation). The swap file always exists ensuring that storage is more or less guaranteed.
With Xen memory overcommit seems to be a bit of an after thought, with only allowing balloning (via DMR) within the virtual machine and forcing it to use its own swap (if provisioned) within the virtual machine on the virtual disk. This is not only slower but also make the machine misreport its memory usage to tools like munin.
I think this was one of the reasons why Amazon disable balloning in EC2. It exposes too much information to the virtualised machine.
-
@markds said:
@scottalanmiller Just thought of another upside. I think ESXi manages swapping better. Every vm has a preallocated swap file at the hypervisor level equal to its assigned memory.
Absolutely, VMware remains the general technology leader. No question there. Everyone plays catchup with few exceptions, one being PV and PVH in Xen that no one else can touch, and MirageOS, but the real question would be, in the SMB how many people are swapping on their VMs, and how important is hiding details if they do?
In the enterprise on massive scales, yes, there can be some huge advantages here. But this seems like a niche case in the SMB. The cost of VMware Essentials alone would be more than the total memory budget of an SMB. Use the money to buy enough hardware to avoid swapping and suddenly the performance advantage goes from nominally in VMware's court to dramatically in everyone elses', right? A normal SMB only has around 64GB - 128GB total server memory across all systems. $500 from not needing an up front VMware license would be enough to double that and still save money, and I don't see many SMBs running out of memory and swapping anyway.
-
It has been half of a year and I am circling back around. No question that VMware has some unique advantages, but also it seems pretty clear that very few of these typically make sense in the SMB market (things like improved swap handling don't pay off when the additional licensing cost could have purchased more memory to avoid swapping, for example.) So only very specific deployments benefit from most of those things.
Now that XenServer 7 is out and Hyper-V 2016 is nearly out, how is VMware holding up in the SMB space? Are there new advancements to put VMware back onto the map, or have they fallen farther behind?
-
@scottalanmiller I kind of look at it slightly a different way... In Aus, the essentials license costs $1,025, for 3 hosts and 3 years of support. Which to me is fairly cheap, esp given that you get phone support.
Therefore, one could rephrase the question as, should I pay $100 per year per host for the market leader. However, its not as simple as that....
If SMBs want VM based backups, then most likely will look at something like Veeam, which is ridiculously expensive. in comparison the the hyper-visor license. $3600 for 3 hosts.
So I think the real question how much will my entire infrastructure licensing costs be, between Xen and VMware platforms.
