I am happy to report that I have managed to get the VMware View PCoIP Client to work on openSUSE Linux 12 with the GNOME 3 desktop environment. The first client I tried was the VMware View Open Client, which is an open source project. However the View Open Client does not support PCoIP and only connects to the View desktops using RDP. As I am not a fan of RDP, I was keen on getting PCoIP to work.
Some background as to why I needed the PCoIP View Client to work on Linux:
Generally for remote access to my lab, I use the VMware View PCoIP Client for Windows, Android and iOS (on the iPad). VMware has made the PCoIP client available on all of these platforms, but no Linux PCoIP client has been released. This article should get you up and running, but bear in mind that it is not supported by VMware.
When working on a Linux VM via the VMware Remote Console over a WAN or slow link, the keystrokes sent to the console might end up reppeating. In order to avoind this, perform the following steps:
1. Power down the VM
2. Add the following line to the VMX file (can also be done by editing the Advanced VM settings using the vSphere Client):
keyboard.typematicMinDelay = "2000000"
3. Save the VMX file
4. Power on the VM.
I decided to post this as I keep on forgetting what the fix is. Now I'll know where to find it in the future without having to go to Google ;-)
Following the changes made by VMware to the vSphere 5 vRAM allocation sizes, I've released version 0.6 of my vSphere License Calculator to reflect the new vRAM allocations.
Please download version 0.6 and let me know if you discover any further problems with the calculator.
*The vRAM Entitlement for vSphere Enterprise has now been corrected to 64GB*
The new version of tha calculator can be found here
Following some feedback from the community, I'm happy to release version 0.5 of my vSphere License Calculator.
The main issue that has been fixed in this release is a flaw in the formula that calculates the vSphere 4 License count based on the CPU core count.
The problem was discovered when a user tried to calculate licenses based on 7 core CPUs. This had highlighted a major flaw in the original formula for calculating vSphere licenses. The formula for calculating vSphere 4 Licenses has therefore been rewritten from scratch.
Please download version 0.5 and let me know if you discover any further problems with the calculator.
The new version of tha calculator can be found here
After receiving reports from the community of some issues with the calculator, I've decided to release version 0.4 of the vSphere 4 and 5 Licence Calculator.
In addition to some bug fixes, this version also displays a graph for each edition of vSphere, instead of just Enterprise Plus.
The calculator can be downloaded from here
This is just a quick post to say that my vSphere License calculator has now been updated to Version 0.3.
The following changes/updates have been made:
- The term "cluster" has been removed
- “Memory Utilization” has been more accurately replaced with vRAM Allocation
- Narrow Columns have been “stretched”
- Extra fields have been added to display CPU core Entitlements for vSphere 4 Editions
- The Enterprise Plus Calculation and Chart/Graph has been reformulated to allow for vSphere 4 to be more expensive when CPUs with more than 12-cores are in use.
- A Virtual Machine Capacity Calculator based on Allocated vRAM has been added
- The general layout of the calculator has been improved
- Calculation fields have been re-ordered to make better logical sense
I have decided to publish a BETA version of the tool I quickly made a day or two ago in order to calculate vSphere 5 licenses figures. This is the tool that I used to compile the data from my previous post, titled A Deeper Look Into VMware vSphere 5 Licensing.
Please keep in mind that this is a very simple tool and it i very much still in the early stages of development.
The calculator can be downloaded from here
This tool can be used to calculate the license requirements for vSphere 5.
WARNING: By downloading this tool, you agree to the following statement(s):
This calculator is provided free of charge with no warranty provided. The use of this calculator is at your own risk. The author or distributor of this tool cannot be held liable for any loss or damages as a result of using this tool. This calculator has not been approved or funded in any way shape or form by any software vendor, reseller or partner, including VMware, Inc.
The rules and figures used in this calculator are subject to change without prior notice.
Last night I posted an article where I showed my initial findings in regards to the changes in vSphere Licensing. In the post I showed just how much more VMware customers will have to fork out to upgrade their environments to vSphere 5. I also included some tables which showed the figures.
After looking into the licensing issue a little deeper, and after spending some time on the phone with my good friend Tom Howarth (from http://www.planetvm.net), I realized that the whole licensing thing isn’t as straight forward as my original post might have pointed out. I’m going to try and explain myself and Tom’s findings.
The first conversation I had with Tom this morning really turned into a session in which we had exchanged our feelings of disbelief and annoyance in regards to where the new licensing model would leave our customers. About half an hour to an hour after that conversation had finished, Tom gave me another call in which he said: “It’s not as bad as we had first thought”. I guess that is what really (indirectly) triggered this post.
Both Tom and I did some calculations on our own and came to the same conclusion. Although we are not entirely in favor of the new licensing model, it does seem to, in certain conditions, force you to stay with recommended best practice in regards to N+1.
I’m going to try and start off with some simple examples to illustrate just what the new licensing model would mean in terms of money.
Bear in mind that in vSphere 5, the licensing will be based on “pools” of resources which I understand is per “vCenter Server instance”. I assume that licenses can move around not only between clusters, but data centre objects as well. However, I could be wrong, so don’t quote me on that just yet.
For simplicity, I’m going to assume that we have a single vCenter server that manages a single cluster of ESXi hosts.
In my first example, I’m going to keep it real simple. In this example we have a single ESXi host being managed by a vCenter server. The ESX host has two 12-core CPUs and 64GB of RAM to start with. The calculation looks as follows:
In the table above, we see that it actually costs more to run vSphere 4 Enterprise than vSphere 5 Enterprise or Enterprise Plus. Also, notice that we require more vSphere 4 Standard and Enterprise licenses as what is required for vSphere 4 Enterprise Plus as well as all of the vSphere 5 Editions. This is because of the 6-core CPU limit on vSphere 4 Standard and Enterprise Editions.
Other than that, there’s not much else to say about the calculation above, so let’s double the memory in that host to a figure that I’m more likely to see more often in my customer environments.
Ok, the table above shows a little more about the penalty that will be paid in terms of vRAM TAX. Because there is now more than 96GB of RAM, an extra CPU license is required to legally make use of use of 100% of the physical memory.
However, as a single host is not very realistic, I’m going to up the ESXi hosts to 4. Let’s see what happens.
The table above shows 4 ESXi hosts. Although the licensing looks bad, keep in mind that we are planning to use 100% of the physical memory in the host, which is not a good idea in terms of HA and N+1. It is also very bad design practice.
So to get ourselves into a better position in regards to HA, let’s apply a rule that states we have to leave 25% headroom in terms of cluster wide memory.
As a result of applying a rule that states that we are only allowed to use 75% of the TOTAL cluster’s physical memory resources, the licensing seems to be more on target, with an equal license count between vSphere 4 and 5. Also, because of the CPU core limit in vSphere 4, notice that with the Enterprise license, vSphere 5 actually works out cheaper than vSphere 4.
Now here’s the trap. Let’s up the Target Physical memory Utilization figure to by 1% to 76% and see what happens.
As soon as we use 76% of the cluster wide physical memory resources, we are required to purchase another license. The biggest issue I have here is that VMware now contradicts itself in terms of features and licensing. For example, they would like to sell vSphere as the “clever” solution that will sort out resource contention with things like Resource Pools (Proportional Share-Based Algorithm) and Transparent Memory Page Sharing, but on the other hand, they tax you for using those features.
In the figure above, vSphere 5 is more expensive as we only have two CPU sockets in each host and are aiming to utilize 100% of the physical memory. As said before, this is a bad design!
The figure above shows that with the reduced Max physical memory utilization of 75%, vSphere 4 and vSphere 5 is on equal footing in regards to price. However, the catch is detailed in the graphs below:
The figure above starts to reveal the vRAM tax. Simply because we use 1% more than 75% of the physical memory, we now require an additional CPU license on vSphere 5
Now the figure above shows just how the vRAM tax is applied. The next figure will make it even clearer.
Ok, so we can clearly see that from the images above, based on 128GB of RAM per host, which I have to say, based on my experience, is an average amount of RAM for today’s blade systems, the penalty get’s heavier and heavier with every host you add to the environment.
Now, if you do end up in a situation where you need to purchase additional licenses, the only thing that can think of to cushion the blow a little would be to double the amount of physical processor packages in each host, if you have the empty sockets available to do so. Probably the worst thing I can think of is having a situation where you have more licenses than physical CPUs and still have empty CPU sockets. At least, by filling the empty CPU sockets, you’ll have the option of additional CPU resources.
On July 12, 2011 at about 16:00GMT, VMware announced vSphere 5 and a bunch of changes surrounding the product suite. During the event, Twitter was ablaze with updates with regards to what was being revealed by VMware. However, one of the changes seemed to have caused some concern amongst the trusted virtualisation community. The change to the vSphere licensing model is what seems to have been discussed quite a bit on Twitter.
I’m not going to expand by giving details on the licensing changes, for more information on the new licensing model, see the link below:
At first I wasn’t going to write up on this as the blogging community already came out and published pre written posts as soon as the VMware NDA time expired at 16h00 GMT. Also, I’m pressed for time at the moment, so I’m rushing this one and the research done on this post in.
After doing some number crunching, I came to a disturbing conclusion. Unless my calculations are way off, and unless VMware is drastically going to reduce the “per license” price tag, the new licensing model will offer a raw deal to VMware’s customers.
As far as I am aware, VMware has not yet published the price list for vSphere 5. As I really wanted to see what implications the new licensing strategy was going to have in terms of today’s prices, I did some calculations using today’s vSphere 4 license costs. As I said, unless VMware reduces the price per license, it would be almost impossible to sell the product to some of my current customers who already think that VMware vSphere is too expensive in comparison to rivals such as Microsoft’s Hyper-V. Well, unless I’m very wrong, it’s about to get worse!
Now, bear in mind that I did these calculations in a rather short period of time. I’ve not done a whole bunch of research on the new licensing model yet, but went by what the PDF stipulates. I could have made a fundamental mistake somewhere, and I really hope that I am wrong on this.
Please, if anyone can find a major error somewhere in my figures, please let me know.
I based my calculations on the following template as most of my customers typically run a similar setup;
- 2 CPU sockets
- 12 Cores per CPU
- 128GB per Host
I compared what the new vSphere 5 model would cost in comparison to the vSphere 4 licensing model. The results are truly staggering!
Also, to give vSphere 4 a level playing field in terms of memory assignment, I assumed that we would want to be able to use up to 100% of the physical memory in the cluster, as this would not carry any penalty in terms of vRAM TAX in vSphere 4. Now I know that the license on vRAM is on allocated and not on total physical memory, but for an apples and apples comparison on possible memory consumpsion, this was the most straight forward way of calculating the numbers.
Below are my results. Now if I have made some mistakes here, please let me know. I’m looking for constructive comments here! An argument is not going to help anyone