What is the Upside to VMware to the SMB?
-
@markds said:
@scottalanmiller Ok I'll bite.
From our experience VMware is far more performant, especially when resources are highly contented. This is something that can happen in an SMB environment where their budget limits them to only purchasing 2 hosts.
Whilst, I have seen benchmarks that indicated the reverse but they were primarily based on cpu / mem throughput. In real world usage, VMware's IO emulation appears to be faster. This was particularly the case for us when virtualising the few Windows machines we had.
Sensible. That VMware's IO emulation is better is not surprising, I have no doubts around it having the superior technology. Their architecture alone is the best out there.
I've seen SMBs report Xen beating it at 20% this past year, not from cpu/mem tests but in actual VM density after migrating the workload directly from VMware ESXi to XenServer. But every workload is different. If they were not IO bound, for example, your situation would not likely apply to them.
What additional density have you seen with VMware and which platform(s) was it outperforming?
-
@markds said:
One big feature you miss out with the VMware Essentials license ($500) is vMotion. However, whilst you do get that with Xen Server, it appears to require shared storage. Something the SMBs shouldn't have.
You are right that SMBs should not have shared external storage. But XenServer can do replicated local storage (RLS) using no external components which would provide vMotion as well as high availability (at the platform level.) It also has the Storage vMotion equivalent as well.
All of this is new, or most anyway, since you made your switch away from it.
Two years ago I was espousing VMware as well. It is only the recent changes to the Xen and moreso the XenServer ecosystems that have prompted the changes there. I've always been a Xen fan, we used it before VMware starting in around 2003, but XenServer I avoided until recently due to the Citrix entanglements and we had a VMware license.
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.
-
-
@markds said:
Granted this is a) a small sample size 2) comparing VMware with Xen under Redhat (as opposed to Xen Server) 3) we moved to VMware 2 years ago and haven't looked back
Xen under Red Hat, while not officially supported by RH last I knew, should be, in theory, identical to XenServer under most configurations since XenServer is using CentOS as their Dom0 anyway. Would be the same kernel, at the very least, unless it was an older version of Red Hat. Do you know what Xen version it was? Xen 4.4 is current.
-
And, of course... welcome to the community!!
-
@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.
Virtualising linux VMs was excellent under Xen until we pushed cpu contention beyond a ratio of around 4x physical cores. 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).
-
@scottalanmiller said in What is the Upside to VMware to the SMB?:
And, of course... welcome to the community!!
Thanks!
-
@scottalanmiller said:
Do you know what Xen version it was? Xen 4.4 is current.
The last version we ran in production was v4 but I think we tested 4.3.3
-
@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"
