Re: [zones-discuss] Zone Migration with Resource Bindings

2007-10-05 Thread Jerry Jelinek
Jim,

Jim Mauro wrote:
 Does Zone migration factor in resource allocations?
 If I have zoneA on sysA, and have configured
 zone.cpu-shares, or some other resource control,
 does the migration process, and/or the dry-run feature
 check for availability of configured resources, or is this
 simply required due-diligence on the part of the administrator?

No, this is not automatically handled.  The admin has to
make any adjustments needed.

 Do the resource bindings migrate, or do they need to be
 redone after the migration has completed on the target system?

I am not sure what you mean by bindings.  The RM settings in
zonecfg will migrate if you create the zone on the new host
using the create -a option in zonecfg.

 Are there plans to broaden the constraints on migration in terms
 of the source and destination machines matching uname -m,
 so I can migrate SPARC-to-SPARC (e.g. sun4u to sun4v) ?

This is

6576592 RFE: zoneadm detach/attach should work between sun4u and
 sun4v architecture

I have prototyped a solution but I have not yet had a chance to
finish the work.

Let me know if you have more questions,
Jerry

___
zones-discuss mailing list
zones-discuss@opensolaris.org


[zones-discuss] Zone Migration with Resource Bindings

2007-10-05 Thread Jim Mauro

Does Zone migration factor in resource allocations?
If I have zoneA on sysA, and have configured
zone.cpu-shares, or some other resource control,
does the migration process, and/or the dry-run feature
check for availability of configured resources, or is this
simply required due-diligence on the part of the administrator?

Do the resource bindings migrate, or do they need to be
redone after the migration has completed on the target system?

Are there plans to broaden the constraints on migration in terms
of the source and destination machines matching uname -m,
so I can migrate SPARC-to-SPARC (e.g. sun4u to sun4v) ?

Thanks very much,
/jim

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] ipfilter in local zones

2007-10-05 Thread Dan Gubber
Here's my feedback.

We are running a fare number of solaris containers, across a series of 
supported subnets. As of the Solaris 10 R3 release ( release 11/06 ) it was not 
possible to use ipfilter for the loopback packets between zones.

With R4 ( Release 08/07 ) you now can by having the first non-commented line in 
the ipf.conf file on the global zone as follows:

set intercept_loopback true;

Also, I need to clarify a definition so to speak. The difference between 
trunking and tagging can be a bit misleading, especially if you're old school 
like myself having done this job now for coming on 30 years.

The term trunking, in the old days, meant the extension of the physical network 
to the server in question, ie, no defined VLAN on the switch ports. SUN's use 
of trunking actually defines the method of device aggregation for HA network 
connectivity. Last I looked, dladm is the utility to define device aggreagtion.

Tagging defines a virtual NIC on the Solaris server, which passes a VID to a 
tagged port on your network switch determining which VLAN the packet is to be 
sent on.

quick config can be achieved with something like

ifconfig e1000g1001 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255 plumb
ifconfig e1000g1001 up
ifconfig e1000g2001 10.0.2.1 netmask 255.255.255.0 broadcast 10.0.2.255 plumb
ifconfig e1000g2001 up

or you can create /etc/hostname.e100g1001 and /etc/hostname.e100g2001
with the associated addresses in them.
 
The new ability to set the zone's ip-type to exclusive does in fact create a 
much better security model as far as looped back packets on the same global 
zone is concerned, but as mentioned, at a cost. Even if the physical NIC is set 
as a tagged NIC ( ie a VNIC ), it can only be used by a single Solaris 
container. This obviously can become problematic if you are deploying a larger 
number of containers on a single global zone.

I have tested isolation capabilites at the global zone layer using a series of 
rules in the global zone's ipf.conf with very good results. Entries similiar to

block in quick proto tcp/udp from x.x.1.0/24 to x.x.2.0/24 keep state
block out dup-to e1000g1002 quick proto tcp/udp from x.x.1.0/24 to x.x.2.0/24 
keep state

will achieve isolation between subnets and/or containers at least on the same 
global zone, and if a infrastructure firewall is in place as well, the 
duplicate packet will be forced out the NIC/VNIC defined.

Other options like route add zoneA's IP zoneB's IP -interface -reject can 
also be used at the global zone, but this command would have to be initiated 
after zoneA and zoneB are already booted so that the global zone's IP-Stack has 
record of the IP addresses in use. this also would require a series of entries 
to add the rejection for any combination of activity based on the local zones 
installed.

As for the raw use of VNIC's, it works great. Our environment currently 
supports 8 VLAN's on each global zone, and we are able to dynamically add new 
ones when required.

Regards,
Dan G
 
 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org