A client plans to move a database engine to a VM while upgrading to SA12. Currently they use SQLA 9 with 1 processor licence which covers 2 physical processors. The licence model for SQLA 12 is different, each physical processor requiring a separate licence.
I googled for hints on that topic and found that page:
But that didn't get me very far, there's no such simple case with only one instance or SQLA.
The new machine might have 2 or 4 quad core processors (I don't know yet). I'm a newbie when it come's to virtualization (apart from using VM's for test environments). So I'm unable to imagine how to count processors in a VM.
Reimer, In version 9.0, we sold a 2 CPU package. So, your comment that your version 9.0 "1 processor licence which covers 2 physical processors." is actually incorrect. After version 9.0, we changed the packaging, so it is only a 1 CPU package.
Therefore, in version 12.0, you need 2 of the 1 CPU licenses.
Now, to your actual question: The license is on the number of CPUs, and NOT the number of cores. On a machine with 2 quad-core processors, you will need 2 CPU licenses.
Now, to answer the question about Virtualization. A VM is treated by our license as a machine. There is nothing special about virtual machines. The "machine" that you are running SQL Anywhere has to be properly licensed for the number of CPUs that you want your SQL Anywhere Server to use.
answered 11 Nov '10, 21:10
As I understand it, the software running in a VM thinks it is running on real hardware. In that sense, if the VM is only presented with 1 processor (whether this comes from 1 of many real physical processors, or merely 1 core of a multi-core processor) it will only be able to see the 1 processor.
That is how the software itself would interpret the situation. How Sybase as a company would interpret the licensing is another matter. I am not sure if they license based on actual physical processors on the box housing the VM (which in a large scale VM setup could change at any moment) at that point or again the processors presented to the VM itself.
This is all conjecture. Please correct with real Sybase-certified info.
answered 11 Nov '10, 20:03
I talked to Sybase sales in Germany. To make it short, this is the summary of our conversation :
That sounds logical, if I assume that applications running in a virtual machine can't tell if a processor is "real" or "virtual".
answered 28 Mar '11, 06:03
My observation at a client site using VmWare: they "allocate" the number of processors to each VM they create. So the hardware has 2 CPUs, they allocated only 1 CPU to our database server, so when I look in Control Panel/System on that VM it says it is running on a 1 CPU machine. Therefore they purchased a 1 CPU license. (If I understand correctly, a 1 CPU license will automatically only use 1 CPU even if the hardware has more than 1 CPU. So I think the licensing takes care of itself in that regard.)
answered 12 Nov '10, 19:43
This isn't an answer, it's an exhortation: Be prepared to hear your client complain about performance problems after virtualization. Maybe it won't happen, but... if the current non-virtualized database engine uses, say, only a small percentage of the CPU capacity, it may be a good candidate for virtualization... unless it also does a lot of disk I/O and that disk I/O is optimized by heavy use of the RAM cache, and after virtualization the database is starved for RAM, and the hard drive light comes on and stays on 24 by 7.
Caveat Emptor: I have zero personal experience setting up database servers on VMs, and very little second-hand knowledge... 100% of that being tales of woe. My simplistic answer is always "get off", like the simplistic medical advice "if it hurts when you do that, stop doing it."
Of course, clients don't often call and tell me when things are going well so perhaps there are many success stories :)