Hi Mike and Trevor, Thanks for your reply. Yes, you are right. This scheme do have defect. From the customer view of point. If the license is base on number of cores, they only want to pay for the cores they use, so within LDOM, they only pay for the CPUs assigned to that LDom. And If they have already paid for a core, within a LDom, they don't want to pay for it again within other LDom. (In this case, the two LDoms share that core). Out scheme is aim to fulfill this purpose. If it difficult to implement this scheme, do you know any other license scheme to support virtualization?
Date: Mon, 30 Nov 2009 14:23:01 +1300 From: [email protected] To: ldoms-discuss at opensolaris.org CC: bilishr at hotmail.com Subject: Re: [ldoms-discuss] licence issue on ldoms Not to mention it's been a waste of time on Solaris since about forever. Whatever "thing" you decide to license against can be changed. For example, "sethostid" programmes have been around since at least SunOS 3.5 and with dtrace it's so trivial to change it's a joke. And don't forget whatever UNIX command you pick can be defeated, by replacing whatever commands you run to a shell script that is echo "expected result". Mike Gerdts wrote: 2009/11/27 JoeBilish <bilishr at hotmail.com>: Hi All, we are triying to associate licenses with the ldom and machine. they can use for sub-capacity and shared-capacity licensing purposes. The concept is that customer can create a ldom that use fraction of the machine processor and we provide a license locked to that ldom. or we provide a machine level license locked to whole physical machine. ldom created on the same machine can share the machine level license. To implement this. we need a machine and ldom identifier. Also, we need to get those identifiers and processor number of the machine and ldom from within ldom. Is there any way to get those information? By doing these types of things, you are preventing your customers from using many of the benefits of virtualization. I think that your intended licensing scheme only supports segregation of workloads. Virtualization is also done for the purposes of providing application agnostic failover (in the event of hardware failure or planned maintenance), dynamic capacity management (the network on box A is saturated, let's move ldoms 1, 2, and 9 to a different box), and optimized asset management (lease on box B is up, let's migrate ldoms to its replacement). Node locked licenses were a pain to deal with 10 years ago. Today they mess up virtualization management strategies enough that it forces node-locked applications to specific devices. This quite likely leads to underutilized dedicated hardware. That, in effect, drives up the customer's cost of deploying your software while driving down the customer's ability to manage the underlying OS and hardware platform using their or industry best practices. As much of a pain as FlexLM is for some to manage, a floating "number of seats" (number of CPU's, gigabytes of RAM, etc.) based license is much more palatable. In either scheme, you need to trust your customer at some point (and leverage appropriate copyright laws as required). License management software can be very helpful for customers that don't want to exceed their license limitations. Customers (or non-customers) that want to defeat your license management software can do so in a variety of ways, ranging from faking host ID's to editing the machine code in your executables to have the licenseCheck() function always say "unlimited permanent license". (For the record, I do not advocate violating license terms.) www.eagle.co.nz This email is confidential and may be legally privileged. If received in error please destroy and immediately notify us. ????????????? ????????????????! ????? _________________________________________________________________ ?Windows Live ???????Messenger2009???? http://www.windowslive.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/20091130/5fc3d468/attachment.html>
