What is the Upside to VMware to the SMB?
-
@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"
-
@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.
