Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008]

[Brian Ruthven - Sun UK]

Hi Jordan,

Personally, I'm fine with this, but wanted to make sure all bases were 
covered. I too would prefer the hostid to be a zone configuration 
parameter rather then a /etc file within the zone itself, leaving it to 
those who configure the zone to set it, rather than the super-user 
within the zone.


> My solution for NGZ hostid emulation is to add a 32-bit integral field to the
> zone structure zone_t that will contain the zone's hostid or HW_INVALID_HOSTID
> (-1) if the zone does not emulate a hostid.  The GZ's hostid will be the host
> machine's hostid, which will be stored in hw_serial.  NGZs will not emulate
> hostids by default.

Just to clarify: What value is returned by sysinfo(SI_HW_SERIAL) within 
an NGZ if /bin/hostid is run in the case where emulation is disabled?

Thanks,
Brian


Jordan Vaughan wrote:
> Brian Ruthven wrote:
> > Just to make sure this has been covered:
> >
> > PSARC/2007/078 (hostids for x86) mentions the legal implications of 
> software licensing against hostids. This case proposes that the 
> hostids are user-supplied, thus may need a Sun Legal check too.
> >
> > Brian
> >
>
>
> If I remember correctly (please correct me if I am misunderstanding 
> your reference), the concern in the PSARC/2007/078 mail was that 
> placing the system's hostid in an /etc/hostid ASCII file would not 
> only invite more license circumvention, but also make it appear as 
> though we (Sun) are encouraging license circumvention and thus 
> betraying our ISVs that use hostids for licensing.  Are you concerned 
> that non-global zone hostid emulation might have similar 
> consequences?  If so, then I would argue that the concern is 
> unwarranted in this case.
>
> We must remember that zones are configurable virtualized execution 
> environments, like virtual operating systems.  (I say this not because 
> I think you do not already know it, but to focus our attention on the 
> purpose of zones in order to make a more salient point.)  They are 
> *meant* to look and feel like machines distinct from their physical 
> host.  Emulating hostids is simply another way to customize the 
> virtualized environments that zones provide so that system 
> consolidation can be more easily facilitated with zones and zone 
> migration across physical nodes can be more flexible when legacy 
> licensed software is in jeopardy (as my case states).  We are 
> providing non-global zone hostid emulation for these reasons alone and 
> should clearly state this in our documentation (as I made an effort to 
> do in my proposed man page changes).
>
> It is possible that license circumvention might increase slightly with 
> the introduction of non-global zone hostid emulation, but I doubt that 
> it would be a significant increase.  For one thing, faking hostids is 
> already possible and easily accomplished (for example, see 
> http://www.software.com/downloads/purchase/Solaris-Hostid-Controller-buy833075.html). 
>  If a user wants to circumvent hostid-based licensing, then he can do 
> so today in a variety of ways at little or no cost (except perhaps two 
> minutes of his time) with Sun-developed technologies.  Adding 
> non-global zone hostid emulation will not open any new doors to 
> unscrupulous users.  Additionally, using non-global zones for the sole 
> purpose of circumventing licensing for a handful of programs is a 
> relatively expensive solution to an easily-solved problem.  Zones take 
> disk space, cpu time, and memory, whereas a five- or six-line DTrace 
> script that intercepts sysinfo(2) system calls is much cheaper.  
> Non-global zone hostid emulation will not enlarge the hostid-based 
> licensing circumvention problem that our ISVs already face.
>
> Furthermore, I claim that if users were to abuse hostid emulation to 
> circumvent software licensing, a use which would not fall within our 
> stated (documented) intentions for the technology, then we would not 
> be responsible for their actions.  If arguing that the potential for 
> such abuse justifies rejecting non-global zone hostid emulation, then 
> destructive DTrace scripting should be eliminated because of the 
> ability it grants users to (easily) circumvent hostid-based software 
> licensing.  However, I imagine that we would not eliminate destructive 
> DTrace scripting or consider providing it a betrayal of our ISVs 
> because such abuses fall outside of the stated purposes for the 
> technology.  If that is the case, then non-global zone hostid 
> emulation should be permitted as well.
>
> My two cents,
> Jordan

-- 
Brian Ruthven                                        Sun Microsystems UK
Solaris Revenue Product Engineering             Tel: +44 (0)1252 422 312
Sparc House, Guillemont Park, Camberley, GU17 9QG