Re: [zones-discuss] Cannot export EMCpower device to local zone

2010-04-29 Thread Tommy McNeely
Hi Joe,

As a general rule, its a bad idea to export disk devices to a zone. There is no 
efficiency gained by doing so. These are not virtual machines, there is only 
one kernel running. Just create a filesystem (zpool create ...) and share the 
dataset with the zone. The zone will have full control of the dataset and any 
child datasets it creates.

Now that thats out of the way... I don't think you can add devices like that to 
an existing zone, install a new zone with that config and the devices will be 
created at install time. You might be able to mknod the devices in the zones 
dev folder, but make sure you understand what you are doing, and heed my 
above statement :)

Tommy



Tommy McNeely | Programmer Analyst-IT | +1.303.395.3361
Oracle Global IT - Service Design
500 Eldorado Blvd, Broomfield, CO 80021

On Apr 29, 2010, at 9:26 AM, Joe Balenzano wrote:

 Well according to this:
 
 http://www.emc.com/collateral/support-training/support/300-003-593-powerpath-for-solaris-rn.pdf
  
 
 You did everything correctly.  Are there entries in /dev/dsk and /dev/rdsk  
 for the powerdevices in the global and non-global zones? Does format in the 
 global zone display them?  Also check the output of zonecfg  -z yourzone 
 info to make sure you really added the devices
 Does the EMC inq command tell you they are there?
 
 Ashit wrote:
 I am unable to export the emcpower device to local zone.
 here are the steps followed:
 A) put following entries in /etc/devlink.tab
 type=ddi_pseudo;name=emcp;addr=0;minor=a,blkdsk/emcpower\A0\M1
 type=ddi_pseudo;name=emcp;addr=0;minor=a,rawrdsk/emcpower\A0\M1
 type=ddi_pseudo;name=emcp;addr=1;minor=a,blkdsk/emcpower\A0\M1
 type=ddi_pseudo;name=emcp;addr=1;minor=a,rawrdsk/emcpower\A0\M1
 B) reboot the host
 C) Halt the zone say ZONE1
 D) add following entries in zonecfg
 device
match: /dev/rdsk/emcpower0a
 device
match: /dev/dsk/emcpower0a
 E) boot the zone
 
 I don't see the emcpower device being exported in the non-global zone. used 
 format command to check that on non-global zone.
 EMCpowe version = 5.0.0
 Can someone help me here.
  
 
 
 ___
 zones-discuss mailing list
 zones-discuss@opensolaris.org

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

[zones-discuss] NV120 - IPv6 shared-ip zones

2009-08-10 Thread Tommy McNeely

Hi zones experts,

I have a couple exclusive ip zones using IPv6. One is the  
router (tunnel host) and is dual stacked IPv4 and IPv6 running a 6  
in 4 tunnel to Hurricane Electric, and the other is a simple web server.


I am trying to create another simple web server that is on a shared-ip  
type of zone. The global zone is not on IPv6 at all. When I try to set  
the defrouter attribute of the net device, it complains that IPv6  
addresses require a /prefex-length suffix, but then (presumably due to  
that suffix) it fails to add the default route.


I tried editing the XML file directly to remove the /64, but it still  
says its unable to set the route for interface (blah) to (ipv6-gateway- 
ip).


Am I doing something wrong here? Has this been tested (local zone on  
(routable) IPv6, global zone not)?


Thanks in advance,
Tommy
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] can't unset defrouter ?

2009-04-17 Thread Tommy McNeely
OK, my bad, I referenced the help information, and it didn't give me a 
remove option at that point.


I used remove to axe the entire net device, but didn't try the 
undocumented remove attribute while inside the net device.


~tommy


Konstantin Gremliza wrote:



exactly:

zonecfg -z donald
zonecfg:donald info
zonename: donald
zonepath: /zones/donald
brand: native
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
...
net:
   address: 10.2.140.150/16
   physical: e1000g0
   defrouter: 10.2.0.1
net:
...:
zonecfg:donald select net address=10.2.140.150/16
zonecfg:donald:net remove defrouter 10.2.0.1
zonecfg:donald:net info
net:
   address: 10.2.140.150/16
   physical: e1000g0
   defrouter not specified
zonecfg:donald:net end
zonecfg:donald exit



Konstantin

Hugh McIntyre wrote:

Tommy McNeely wrote:
Once a defrouter is set, there doesn't appear to be a way to unset 
it. I have added another (public) IP address to this zone, and with 
that public IP its own defroute. I want to keep this private one, 
but remove the defrouter attribute. There is no unset and you 
can't set it to  .. I can obviously remove it and re-add it, but 
shouldn't there be an unset?



zonecfg:blah-amer:net info
net:
   address: 172.168.134.151
   physical: aggr634001
   defrouter: 172.168.134.1


remove is the unset command, I think.  Try:
 remove defrouter 172.168.134.1

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





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


Re: [zones-discuss] ipfilter (ipf.conf) entries in zonecfg?

2008-11-12 Thread Tommy McNeely
Well, I forgot to mention that we were using S10u6, but the idea I had was to 
apply the filter rules in the global zone. As far as I can tell, crossbow is 
not integrated with NV or OS either :)

It looks like we are going to need to somehow wrapper it, or put the entire 
ipf.conf for all zones on all physical nodes.

Thanks,
Tommy
-- 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] chroot env into zone

2008-11-12 Thread Tommy McNeely
Start with a real minimal build of Solaris, build a sparse zone. The zones then 
take ~200MB. No, its not a CHROOT, but you can chroot apps that support it 
(named) within the zone so that there is absolutely nothing that can be 
accessed if it somehow is broken... but the minimal install should reduce your 
patching requirements and the sparse zone makes it so that IF someone breaks 
in, they can't break most of the executables as they are on a read-only 
filesystem.
-- 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] ipfilter (ipf.conf) entries in zonecfg?

2008-11-12 Thread Tommy McNeely
I have about 50-60 zones spread across 3 security contexts ;)

~tommy

On Nov 12, 2008, at 6:38 PM, Ha Bailey wrote:

 Have you considered Trusted Extensions?  As long as you do not need  
 multiple zones of  the same security context on the same physical  
 server, it might work out for you. (in other words, you cant have  
 two internet zones on a single host).

 This might help you:  
 http://www.sun.com/bigadmin/content/submitted/trusted_ext_corp.jsp

 Robert Bailey

 On Nov 7, 2008, at 12:13 PM, Tommy McNeely wrote:

 Hello Zones experts,

 We are attempting to create a new data center architecture that  
 favors
 virtualization with zones. Previously, if we wanted to have zones  
 from
 different security contexts (front-end, back-end, internet, etc),  
 they
 had to be in different physical machines (or LDOMS). Now that we have
 the ability (ok, as of s10u4, but we have been busy) to use ipfilter
 between zones on the same host, we believe there may be enough
 separation to have zones in different security contexts on the same
 global-zone.

 I would like to get people's feedback on what they would think of
 creating the ability to have ipfilter rules, that would normally be
 located in ipf.conf in the global zone, inside the zonecfg. When the
 zone is brought online it could pipe the rules into ipf -f - or
 something. I am thinking the zonecfg seems like a good place to store
 them because when I want to move a zone from one machine to  
 another,
 I would prefer the firewall came along with the zone.

 We have discussed using vnic interfaces (crossbow?), but I don't
 believe thats integrated yet? Besides, we don't really trust the
 application administrator (zone administrator) with the firewall, so
 we'd like to keep its configuration in the global zone, which I  
 assume
 would still work even with vnic's.

 QUESTION: If we put the firewall (ipf.conf) inside the zone and use a
 private IP instance, can they can put a pass out quick on vnic0 keep
 state and they have the ability to connect to any other zone on the
 same machine? I know that rule in the global zone makes it that way,
 but maybe ip stack instances fix that?


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


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


Re: [zones-discuss] static routes vs default routes (zones in different subnets)

2008-11-10 Thread Tommy McNeely

On Nov 10, 2008, at 7:09 AM, Paul Kraus wrote:

 On Sun, Nov 9, 2008 at 10:34 PM, Tommy McNeely  
 [EMAIL PROTECTED] wrote:

 The problem I ran into this time was that static routes don't seem to
 use the same intelligence that default routes do. For example, in the

 snip

At least as of 10U5 your observation is correct. I tried
 getting Sun to recognize this issue via a support case, after 6 to 8
 months of the case being opened, they told me that IP Exclusive was
 the work around and that they would NOT even file a bug or an RFE on
 the static route behavior. Unfortunately, this is a work around that
 really hampers us due to the limitations of the number of physical
 ethernet interfaces we can put in a single box (and the cabling mess
 that goes with it). We have many different security requirements for
 Internet exposed servers, none of which has a particularly high
 load, so it makes sense to put them all on zones on a moderate server
 from a load perspective.

... hence my shared-ip is the only thing available (feasible)  
comment :)




If this has changed, or is being worked on in OpenSolaris, I
 would *love* to hear about it.

Network interface virtualization!

http://opensolaris.org/os/project/crossbow/

I think some of the deep dark kernel stuff is integrated to  
OpenSolaris (and thus Solaris Express), but not everything yet?

~tommy




 snip

 I know this would be made simpler with vnic and private IP stack, but
 in my world, shared-ip is the only thing available (feasible).

 -- 
 {1 
 -2-3-4-5-6-7-}
 Paul Kraus
 - Facilities Coordinator, Albacon 2008
 - Business Manager, Delta-Xi cast of Alpha-Psi-Omega @ RPI
 ___
 zones-discuss mailing list
 zones-discuss@opensolaris.org

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


[zones-discuss] using load balancers with zones

2008-11-09 Thread Tommy McNeely

Continuing on my zones in different subnets theme, but starting a new  
thread to improve readability...

The other problem I have been experiencing can be solved  with the  
right ipf.conf incantation (I think).

Lets pretend the host (zone) mail-fe-1 initiates a connection to  
dirsrv-lb (load balancer) on port 389/tcp. The Load balancer decides  
to send that connection (dnat) to host (zone) dirsrv-1, which happens  
to be on the same physical server (global zone) as the mail-fe-1 zone...
(all networks below are /24)

So, according to mail-fe-1:
LOCAL: mail-fe-1 (172.16.1.51)
REMOTE: dirsrv-lb (172.16.1.30)

... and according to dirsrv-1:
LOCAL: dirsrv-1 (172.16.3.31)
REMOTE: mail-fe-1 (172.16.1.51)

If these are all separate physical machines (or at least one physical  
machine per subnet), there would be no problems, because in order to  
get back to mail-fe-1 (172.16.1.51), the host dirsrv-1 (172.16.3.31)  
would use its default router (the load balancer), which would fix  
(snat) the source address to be dirsrv-lb (172.16.1.30), and everyone  
would be happy. Since they are on the same physical machine, even  
though they are on separate physical interfaces, they find each  
other as the packet is flowing out e1000g3, and comes back in e1000g1,  
but never really gets back because the Local/Remote addresses don't  
match, so mail-fe-1 never sees the S/A. The host based firewall (ipf)  
gets scared and confused and blocks the packet, but I don't think that  
it would even matter if IPF wasn't being used, because I had this  
problem in the past without ipf or any firewall with everything on the  
same subnet. Same issue, the packet was returned directly instead of  
via the wire where it would have (presumably) flowed through the load  
balancer and gotten fixed.

I can obviously workaround the issue by using source-nat in the load  
balancer, causing dirsrv-1 to think that the connection came FROM the  
load balancer (or one of its nat-pool IP addresses) to force the  
packet onto the wire, but that makes logs useless on dirsrv-1 and  
troubleshooting a who made what changes issue a nightmare.

I am sure there must be a way to tell ipf to force packets from the be- 
net to the fe-net to go out on the wire, presumably using dup-to but  
I was unable to make it work, so I am using source-nat at the moment.  
I look forward to hearing that someone else has already figured this  
out and here is how they did it, but for now I need to work on  
installing software on mail-fe-1 because it was supposed to be  
working last Tuesday ;)

Thanks in advance,
Tommy

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


Re: [zones-discuss] Can't create an exclusive IP zone in Open Solaris snv_99

2008-11-09 Thread Tommy McNeely
You probably can't use bge0 because its being used in the global zone. Try 
plugging a cable into bge1 (net1) and use that. Exclusive means exclusive, it 
needs its own network interface.
-- 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Zones hosting providers?

2008-11-09 Thread Tommy McNeely
Sorry that I don't have an answer to your question, but I have some thoughts 
that might help :)

I see zones hosting as two potentially different services...

1. Virtual Dedicated Solaris Server - You are provided a virtual dedicated 
server that runs (Open)Solaris. You know its a zone because you type 
zonename and its not global .. but other than that, they don't really need 
to disclose what kind of virtualization they choose to use. It probably 
wouldn't be marketed as zones hosting or anything to do with zones. As an 
admin, you SSH in and do your thing, just like any other 
virtual-dedicated-server product.

2. ZONE hosting - You somehow provide a hosting provider with a filesystem (zfs 
shapshot?) of your pre-made zone to run in the cloud ... Maybe something like 
network.com or amazon EC (if they were on Solaris). The provider would probably 
have to provide you a virtualbox copy of their hosting environment with the 
exact OS/patches, so you could build your zone and it would zoneadm -z BLAH 
attach without much fuss when you sent it to them.

I don't know whether you are thinking of #1 or #2 or both, but in your 
questioning of service providers, I think if I were you, I would simplify by 
asking them if they provide Solaris virtual dedicated servers, rather than 
zones hosting, as your typical CSR won't know what the heck zones are or what 
they have to do with Solaris or otherwise.

~tommy
-- 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


[zones-discuss] static routes vs default routes (zones in different subnets)

2008-11-09 Thread Tommy McNeely
Hello,

As I previously mentioned, I am working on the possibility of putting  
zones from different security contexts (front-end, application, back- 
end) into the same physical server, which is effectively putting zones  
in more than one subnet. We also like to use a load balancer, at least  
on the front-end net, and increasingly on the back-end nets as well.   
In order to use a load balancer, the general idea is that you set your  
default route on the real server to go through the load balancer. I  
am able to do this fine (s10u6), even without a home brew SMF  
service to add default routes after zones come up like I have had to  
use in the past.

The problem I ran into this time was that static routes don't seem to  
use the same intelligence that default routes do. For example, in the  
global zone I have 4 default routers, each pointing to the default  
router of a local subnet (172.16.1.254/24, 172.16.2.254/24, and  
172.16.3.254/24 (4th is not important at the moment). Inside a local- 
zone with an interface on the 172.16.1.0/24 network, it only sees the  
one default route that it can use (172.16.1.254). That's perfect. The  
problem comes in when I start looking at the admin network. I don't  
want to setup a load balancer service for SSH into each zone, so I  
generally set a static route in to get to the admin network using a  
different gateway (hard-firewall)...

route -p add -net 172.16.250.0/24 172.16.1.1

... of course if I have multiple subnets, I also have...

route -p add -net 172.16.250.0/24 172.16.2.1
route -p add -net 172.16.250.0/24 172.16.3.1

 this confuses zones in the .2 and .3 subnets, as they see all  
three routes and try to use the first one, even though they cannot  
reach 172.16.1.1.

I know this would be made simpler with vnic and private IP stack, but  
in my world, shared-ip is the only thing available (feasible).


Thanks in advance,
Tommy

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


[zones-discuss] ipfilter (ipf.conf) entries in zonecfg?

2008-11-07 Thread Tommy McNeely
Hello Zones experts,

We are attempting to create a new data center architecture that favors  
virtualization with zones. Previously, if we wanted to have zones from  
different security contexts (front-end, back-end, internet, etc), they  
had to be in different physical machines (or LDOMS). Now that we have  
the ability (ok, as of s10u4, but we have been busy) to use ipfilter  
between zones on the same host, we believe there may be enough  
separation to have zones in different security contexts on the same  
global-zone.

I would like to get people's feedback on what they would think of  
creating the ability to have ipfilter rules, that would normally be  
located in ipf.conf in the global zone, inside the zonecfg. When the  
zone is brought online it could pipe the rules into ipf -f - or  
something. I am thinking the zonecfg seems like a good place to store  
them because when I want to move a zone from one machine to another,  
I would prefer the firewall came along with the zone.

We have discussed using vnic interfaces (crossbow?), but I don't  
believe thats integrated yet? Besides, we don't really trust the  
application administrator (zone administrator) with the firewall, so  
we'd like to keep its configuration in the global zone, which I assume  
would still work even with vnic's.

QUESTION: If we put the firewall (ipf.conf) inside the zone and use a  
private IP instance, can they can put a pass out quick on vnic0 keep  
state and they have the ability to connect to any other zone on the  
same machine? I know that rule in the global zone makes it that way,  
but maybe ip stack instances fix that?


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