cancel
Showing results for 
Search instead for 
Did you mean: 

Veritas SF licenses on Solaris zone/containers

posie80
Level 4

Hi all,

I have a question regarding Veritas Storage Foundation 5.1 Basic licenses on Solaris 10 zones/containers.

The scenario :

We are planning to buy a Veritas Storage Foundation 5.1 Basic license for our SUN T5440 server (4 CPUs, 32 cores). On this physical server, we plan to create 3 local zones (containers). All of these local zones/containers will be using Veritas filesystems from the global zone using loopback mount.

The question is now, we would like to move away from loopback mount and mount the raw devices directly on the local zones and configure Veritas dgs, filesystems etc on the local zone itself.  Because of this, we need individual license on the zones rather than installing Veritas SF on the global zone level. In this case, do I need to buy 3 separate Veritas SF licenses for each zone, or is there any way I can use a main Veritas SF license for all these 3 zones? (because technically the server will still use the same number of cpus, we are just creating 3 separate containers on the same server).  I'm not sure from Symantec/Veritas perspective, how licensing works on virtual containers (Solaris zones). So I appreciate if someone can enlighten me on this.

 

Thanks!

Posie

 

1 ACCEPTED SOLUTION

Accepted Solutions

Gaurav_S
Moderator
Moderator
   VIP    Certified

If the zones are booted state, CPI installer should take care of putting the needs into local zones as well..  & yes, pkgadd is the manual way of doing the same..

 

Gaurav

View solution in original post

8 REPLIES 8

Gaurav_S
Moderator
Moderator
   VIP    Certified

Hello,

I would believe that same global zone key should work inside container as well... a permanent node_lock key would be bound to host ID or a normal permanent key as you said is bound with no. of CPUs you use... which ultimately are not changing....

I believe you don't need to buy a separate licenses for zones..

 

Gaurav

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

Hi,

 

Do you mean SF Standard or Basic? Basic is free software but it has limitations

 

Freeware
Storage Foundation Basic exists as a freeware version for small workloads (download at www.symantec.com/sfbasic). This free version is limited to (4) user-data volumes, and/or (4) user-data file systems, and/or (2) processor sockets in a single physical system. For the Windows platform, Storage Foundation does not contain the Veritas File System.

 

If you're referring to SF Standard edition, you can just license the server (as its not too high a TIER, and should not be tooo expensive). This will allow you to run the zones on the same license. Details below......

2.2.2 Licensing for Virtual Server Environments PER SERVER TIER – SF/VCS products for UNIX platforms used in virtualized environments:
•    ALL virtual machines (VMs) or partitions in the licensed server may run the same SF/VCS product and package. •    The “server tier” that a server is assigned is not affected by virtualization or partitioning, even if only a fraction of the
server is running the SF/VCS product. For partially-used servers, the per-CPU Tier meter will likely provide a better
price quote for the customer. •    A server licensed “per-server tier” for UNIX does not entitle the server to run Linux virtual machines (VMs) or partitions.
In order to run any # of Linux VMs or partitions on a server licensed for UNIX by “per-server tier”, customers must
acquire at least 1 (one) S64LNX per-CPU Tier license of the same SF/VCS package according to the cpu tier. •    A SF/VCS Product licensed “per-CPU tier” for Solx64/Linux (S64LNX) does not entitle the server to run Windows VMs or partitions. In order to run Windows VMs or partitions on a processors licensed for Solx64 or Linux, customers must
also acquire SF/VCS for Windows licenses according to Windows edition and # of Windows instances required. See Section 2.3 Licensing for Windows.
PER PROCESSOR (CPU) TIER – SF/VCS Products for UNIX, Linux and Solx64 used in virtualized environments:
To determine the # of CPUs licenses, the following rules apply: •    If the partition or VMs are capped (i.e., its access to processor resources is limited to the amount of processor
resources allocated when the partition was started, or changed through static reconfiguration), one CPU Tier license
is required for every physical processor allocated to the partition or virtual server. •    # of CPU licenses required is a logical quantity and not tied to the physical processor and does not require
implementation of any affinity rule. For example, on a 4 quad-core server, a VM has a 4-core limit configuration, but is scheduled to run on multiple physical CPU sockets (no affinity rules), therefore spanning across more than one CPU. However, for licensing purposes it requires only 1 CPU license since it has a limit of 4 cores = 1 CPU.
•    Resource reservation rules that use relative priority or importance, such as VMware CPU shares, are not considered acceptable means to cap or limit partitions and should be treated as uncapped partitions or virtual servers.
•    If it's uncapped (i.e., the partition's access to processor resources can increase as demands warrant and availability supports), one (1) CPU Tier license is required for each processor in the resource pool. For the purposes of licensing, a CPU resource pool is defined as the total # of CPUs within a single physical server that the partitions or virtual servers can have allocated as demand warrants.
•    On virtualizations technologies that cap or limit partitions, VMs or resource pools using MHz, such as VMware: Limit – MHz, the # of CPU licenses required is proportional to the # of physical processors represented by the MHz. Forexample, in a 4 quad-core server with 48 GHz total capacity (4 CPUS x 4 cores x 3 GHz per core), a VM with a 24
GHz limit requires 2 CPU licenses. •    In the case above, if the VM freely migrates due to automatic resource scheduling to physical servers with different
MHz capacity, the proportion should be calculated for the server with the lowest capacity. •    A license is required for each physical processor included in the partition, virtual server or resource pool even if only
a portion of each physical processor is assigned to the partition, capped or uncapped. •    If multiple partitions, virtual servers or resource pools reside on the same physical CPU, only 1 CPU license required.
The “Processor tier” (Tier 1 through Tier 3) that a processor can be assigned is not affected by virtualization or partitioning, even if only a fraction of the processor, or a subset of the total cores, is running SF/VCS Products.
As an advantage of virtualization and “per-cpu tier” meter, a server might have different packages or versions of SF/VCS on different partitions or virtual servers, the following rules apply:
•    Each capped partition or virtual server can be licensed on a different package or edition according to the # of CPUs licensed according to the rules above.
•    On uncapped partitions or virtual servers, all SF licenses in the resource pool must be of the same package. For example, if a pool of 3 CPUs was allocated to 3 virtual servers, all 3 CPU licenses must be of the same package (e.g., SF Enterprise for each, and not a combination of packages). The same concept applies for partial CPU usage. If multiple partitions or virtual servers run on a single physical processor, the CPU license is for a single package.

posie80
Level 4

Riaan, Gaurav,

Thanks very much for yuor helpful support as always! Your replies make much sense.

Just one additional question if you dont mind : is installing Veritas SF 5.1 supported at all within the local zone? I am currently testing this and the installation is failing due to it not being able to write to /dev (non writable), etc etc. When I try to install it (using ./installer) from global zone, it doesnt seem to propogate to the local zones either.  I know using pkgadd there is a way to make the package be installed on the local zones as well, but I'm not sure if this is the correct way of doing this. Any pointers or document that shows/hints at how we can install the packages (SF) on Solaris local zones?

 

I really appreciate your inputs!

 

- Posie

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

Hi,

 

I'm not too familiar with zones but from what I know you dont install in the local zone. You install in the global, and mount the VXFS file systems either directly or through LOFS.

 

Cheers

 

Riaan

Gaurav_S
Moderator
Moderator
   VIP    Certified

If the zones are booted state, CPI installer should take care of putting the needs into local zones as well..  & yes, pkgadd is the manual way of doing the same..

 

Gaurav

cshoesmith
Level 3
Employee

Guarav is very close to being correct. For the purposes of installing kernel-level packages, the installation occurs on the Global Zone.

The non-global zones need to 'Bootable' state, this is explained in page32 of the 5.1 Solaris Virtualization Guide:

http://sfdoccentral.symantec.com/sf/5.1/solaris/pdf/sfha_virtualization.pdf

 

This doc is the best place to read about Solaris Zones and Veritas Storage Foundation integration.

 

Regards,

Chris

posie80
Level 4

Gaurav, Chris,

Great feedbacks! You provided the answer to my question :) Thanks!

 

Regards

Posie

joseph_dangelo
Level 6
Employee Accredited

Just as a followup, there are no licensing considerations necessary when using Storage Foundation on Solaris with Non-Global Zones.  Whether it is SF Basic/Standard/Enterprise or CFS.  The Global Zone handles the license key repository.  That being said, if you plan on using features such as ODM, you will need to add the following entry to your Zone xml file.

add fs
set dir=/etc/vx/licenses/lic
set special=/etc/vx/licenses/lic
set type=lofs