[zones-discuss] non global zone and NFS server
It used to be that running a NFS server was not supported in a non global zone. Is this till the case? If so are there any plans to support it? What is the reason for not supporting NFS server in a non global zone? Thanks Paul. -- Paul van den Bogaard Sun Microsystems, NL GPE NE Saturnus 1 Xtension:15918 3824 ME AMERSFOORT Office: +31 334 515 918 The Netherlands Mobile: +31 651 913 354 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] non global zone and NFS server
It's being worked on: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4964859 IIRC, it is currently not supported because the kernel part of NFS server does not understand the concept of zones... Rayson == http://gridengine.sunsource.net/ http://www.gridengine.info/ On 10/27/06, Paul van den Bogaard [EMAIL PROTECTED] wrote: It used to be that running a NFS server was not supported in a non global zone. Is this till the case? If so are there any plans to support it? What is the reason for not supporting NFS server in a non global zone? Thanks Paul. -- Paul van den Bogaard Sun Microsystems, NL GPE NE Saturnus 1 Xtension:15918 3824 ME AMERSFOORT Office: +31 334 515 918 The Netherlands Mobile: +31 651 913 354 ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] non global zone and NFS server
Rayson Ho wrote: It's being worked on: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4964859 IIRC, it is currently not supported because the kernel part of NFS server does not understand the concept of zones... In order to help the NFS team understand the importance of this issue we need to make sure that this RFE has customer records attached to it for anyone who is interested in this feature. If you need this feature, please send directly to me, off the alias, your contact information and I will add a customer record to this RFE for you. If you know you are already on this RFE, there is no need to send me the information again. What I need is your name, Company or Organization name, and how severe the impact of this RFE is to you (1-5, 1 is highest). Having this information attached to the RFE will help the NFS team to prioritize this feature against the other work they have on their plate. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] actual utilization of a pool/zone/proj
Amol A Chiplunkar wrote: You may want to add more information like you are creating psets for each pool and the pset.max and pset.min of each. Because when I create a pset without specifying them and associate it with a pool, the size is zero. I thought when you were using a utilization goal instead of counting CPUs you should declare a max to be a really high, unrealistic number and the min to be 1. Is that not what you should do? Also a correction. You cannot specify 50/100 shares. Shares are relative integer values and the absolute value of shares at any point of time can be calculated using total shares of of active entities competing for CPUs. Yes, I know. But it's easier to follow the conversation instead of me putting 1 and 1 down or 6789 and 6789. I would predict that the physical utilization of project_alpha in terms of %CPUs (as shown by prstat) would be (0.25 of poolsize of pool_1) * 100 / 16 i.e. if the pool_1 poolsize is 4, the physical utilization would be 6.25 % That would mean I would have to know how many CPU are in the dynamic pool at any given time which I don't. I expect that in order to have 50% utilization the objective will be set to ~50 value. And pset.max will be set to a value more than 16. In such a case, I would expect poold to try and give out as many cpus as possible to both the pools since the utilization needs to be kept at around 50% while the zones and projects are fully utilizing all the CPU cycles they get. Yes, that is what I want at the pool level. So at one point, poold should reach a static configuration with pool_default with only 1 CPU and the rest of them given to the two pools created. So your saying the dynamic pool daemon with drive the box to a 16-1=15 then divide that by 2 and get 7.5 CPU bound to each pull. I just don't see why I need to care about counting threads (CPUs) when I already know the pool is using 50% of the box. thanks - Amol - Original Message - From: Michael Barrett [EMAIL PROTECTED] Date: Friday, October 27, 2006 6:02 pm Subject: [zones-discuss] actual utilization of a pool/zone/proj To: zones-discuss@opensolaris.org Lets say I have a T2000 with 16 threads. I have the following: pool_1 = dynamic pool with 50% utilization goal set zone_a = 50/100 shares proj_alpha = 50/100 shares proj_beta = 50/100 shares zone_b = 50 shares pool_2 = dynamic pool with 50% utilization goal set zone_c = 50/100 shares zone_d = 50/100 shares To make the case more simple, we will state that all pools and zones and projects are running at the max so the constraints are being forced instead of one Solaris resource entity receiving more than he is allocated due to the FSS share model. Is there anyway to estimate before seeing actual utilization what the physical utilization of proj_alpha would be? Would you just 50% of the physical box to pool_1 divided by 50 shares for zone_a equals 25% of host utilization available for zone_a. Then 50% of 25% (25/50) is 12.5% of raw host utilization available for proj_alpha? Thanks, Mike ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: 3 questions about zones and containers
You can also remove a LOFS mounted filesystem from a running zone with no problem. I do it all the time. To do it, logon to the global zone and umount the filesystem with: umount mount point in the non-global zone Phil This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [Fwd: Reminder: Design review of IP Instances part of Crossbow]]
On Tue, Oct 24, 2006 at 01:41:32PM -0700, Erik Nordmark wrote: Edward Pilatowicz wrote: - how about the opposite scenario. a user configures a zone with without and an exclusive ip instance and sets up a bunch of network configuration inside that zone that would normally only apply to a zone with an exclusive ip instance. then the user boots the zone. does this result in any errors during boot? The same thing would happen as if you today did echo 10.1.2.3 /etc/hostname.bge0 echo 10.1.1.1 /etc/defaultrouter reboot in a zone. This is silently ignored. (Or, as I've seen some scripts do, put IP configuration into $ZROOT/etc/sysidcfg; also silently ignored today.) The way the smf methods are structured in S10 they skip the IP level configuration. The only change introduced by IP instances is the predicate used to test whether to skip. For example, net-physical has these udiffs: -smf_is_globalzone || exit $SMF_EXIT_OK +smf_configure_ip || exit $SMF_EXIT_OK perhaps some kind of warning message should be generated in this scenario instead? something like: Ignoring zone network configuration specified: /etc/hostname.bge0 Current network configuration is dictated by the global zone. To use the network configuration specified within this zone it must have an exclusive-IP instance allocated to it by the global zone. - you mention that no GLD or layer 2 changes will be supported inside zones. your example then mentions aggregations. i'm rusty on remembering all the layers so i'll just ask, are vlans and ip tunnels supported Aggregations can be configured using dladm in the global zone, and then the aggrN datalink names can be given to exclusive-IP zones. VLANs will be supported for GLDv3 devices. (We can't get e.g. the ce driver to have a separate /dev/ceN entry per instance and per VLAN.) IP tunnels work today, but they are not devices but a funny construct using a tunneling streams module. The clearview tunnel project will turn tunnels into GLDv3 links, and they are aware of the implications of IP instances. (I use separate IP Instances on the laptop punched into separate punchin points just for fun.) good to know. - if an a zone is configured with an exclusive stack, will the /dev (and eventually /dev/net) devices associated with that stack also be automatically imported into that zone? if so, then how does this interact with non-native zones? (linux won't be expecting /dev/bge0 in it's namespace. linux uses network devices like /dev/net0.) Yes. The BrandZ merge was done recently, hence is not covered in the design document. One part is getting things like /dev/ip show up in the exclusive-IP zones, and not in the shared-IP zones. This is done by extensions to platform.xml in the form of + !-- Devices to create in exclusive IP zone only -- + device match=ip iptype=exclusive / The other part is e.g. /dev/bge33000, which is done with di_prof_add_dev() as part of the vplat bringup. Should we just limit that to certain brands for the time being? Or we can disable the ability to setup exclusive-IP with certain brands. Suggestions? nit: in zonecfg it's ip-type were as above there's no dash. i looked into it a bit more and as it turns out in linux network devices don't actually have any /dev entries. but we can't simply tell non-native brands not to map exclusive-IP network devices because this could break other zones. (think sn1, belinix, nexenta, etc.) so here's a question. in an exclusive-IP zone, do we have to have network /dev entries in to be able to configure network interfaces? or can all the necessary configuration be done via socket operations? i guess if we need to have access to the device nodes then the easiest thing to do will be to simply map them in and hopefully linux apps will ignore them. if linux apps don't ignore them then we'll have to create /dev and /native/dev as seperate namespaces. (currently they are the same.) if we don't need/want the nodes then we'll have to add some kind of brand callback such that the lx brand can indicate this when you attempt to add in the interfaces. lastly, we'll probably have to add some kind or mechanism that will allow a brand to iterate over all the network devices which have been exclusively allocated to it. (so when the linux brand does ifconfig eth0 plumb we can look at all the available interfaces and plumb one up.) - wrt to brandz, supporting an exclusive ip instance in an an lx branded zone will require the implementation of network configuration interfaces within the lx brand. it will probably involve translating a bunch of ioctls and socket operations. also, looking at a centos machine i see that it uses iptables instead of ipfilters. so all the iptables configuration system calls would need to be translated into their corresponding ipfilters commands.
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: A (large) customer recently asked me to implement a feature whereby they could monitor zone activity via syslog. The motivation is that for this customer, any zone state change not during maintenance windows is a cause for alarm. I've had a similar request in my organization as a means of helping to identify which physical machine a zone is on by viewing centralized syslog data. Arguably, my use case is of limited value unless zones are rebooting all the time (hence no RFE for my use case). So here are my questions: - Do you think this is useful? Yes. - Do you think the log level (Info) is right? daemon.info is *not* logged by default, whereas notice is. (So basically: do you want these messages in /var/adm/messages by default, or not?) Info is OK for normal state transitions. If a reboot fails and it ends up installed rather than running, I would expect that is an daemon.err (or is it daemon.error...) because something went wrong. - Do you think the facility of 'daemon' is OK? With Solaris syslog you can't AFAIK route messages based on the value of 'program' (which in this case is 'zoneadmd'). There's a good RFE! :) 'daemon' works for me. - Any comment about whether the info provided is sufficient? For example, when a zone reboots it goes through numerous state transitions, but I chose to express this as one big transition-- does that work for everyone? Perhaps if zoneadmd is running in a debug or verbose mode (selected by zonecfg(1M) property or /etc/default/zones?) then it could log detailed state transition info to daemon.debug. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On Fri 27 Oct 2006 at 09:11PM, Peter Memishian wrote: So here are my questions: - Do you think this is useful? - Do you think the log level (Info) is right? daemon.info is *not* logged by default, whereas notice is. (So basically: do you want these messages in /var/adm/messages by default, or not?) - Do you think the facility of 'daemon' is OK? With Solaris syslog you can't AFAIK route messages based on the value of 'program' (which in this case is 'zoneadmd'). - Any comment about whether the info provided is sufficient? For example, when a zone reboots it goes through numerous state transitions, but I chose to express this as one big transition-- does that work for everyone? Encouraging programmatic use of syslog seems a step in the wrong direction to me. Surely we can provide a better mechanism to notify them of state changes? Such as? We went down this road with Sun Cluster and arrived at a fairly complex C API which I was never very happy with; as a result we have thus far kept it private. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On Fri 27 Oct 2006 at 06:21PM, Dan Price wrote: Encouraging programmatic use of syslog seems a step in the wrong direction to me. Surely we can provide a better mechanism to notify them of state changes? Such as? I guess my larger point is that I haven't seen us take steps in the right direction. Maybe we have and I'm just not aware of them. To expand a little, the such as? could be SMF, which already has the ability to monitor property values. However, we're a ways off from having each zone appear as a service (and even then, you'd have to know that a particular zone exists in order to be monitoring some particular property in the repository which represents its state). I think that some minimal syslogging is warranted (I've tried to keep it simple here) because we do know that customers have a degree of comfort with syslog, and because it fits readily into various existing 3rd party monitoring packages. As for GPEC, that's what our existing C api is based upon. Take a look at zonecfg_notify_*() in libzonecfg. It's a real horror show but it does solve the get the state and then subscribe to future changes and don't miss anything in between problem. We could potentially build this up into some new command like 'zoneadm monitor' but I don't necessarily see that as being in conflict with doing something in the short term with syslog-- and 'zoneadm monitor' can't be consumed by upper level monitoring agents without a lot of work by lots of other vendors-- I don't see an unconsolidated but versioned and structured messaging strategy as gaining much traction. If we want to do versioning and structured messages *and* tackle the networking and security parts and make a consolidated stream of messages, then I think that could be interesting. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: As for GPEC, that's what our existing C api is based upon. Take a look at zonecfg_notify_*() in libzonecfg. It's a real horror show but it does solve the get the state and then subscribe to future changes and don't miss anything in between problem. We could potentially build this up into some new command like 'zoneadm monitor' but I don't necessarily see that as being in conflict with doing something in the short term with syslog-- and 'zoneadm monitor' can't be consumed by upper level monitoring agents without a lot of work by lots of What if zoneadm monitor -a (all zones) had the ability to spit syslog entries and/or SNMP traps? Perhaps if the SNMP route is taken, a subagent to snmpd(1M) would be the right approach. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On Fri, 27 Oct 2006, Mike Gerdts wrote: On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: As for GPEC, that's what our existing C api is based upon. Take a look at zonecfg_notify_*() in libzonecfg. It's a real horror show but it does solve the get the state and then subscribe to future changes and don't miss anything in between problem. We could potentially build this up into some new command like 'zoneadm monitor' but I don't necessarily see that as being in conflict with doing something in the short term with syslog-- and 'zoneadm monitor' can't be consumed by upper level monitoring agents without a lot of work by lots of What if zoneadm monitor -a (all zones) had the ability to spit syslog entries and/or SNMP traps? Perhaps if the SNMP route is taken, a subagent to snmpd(1M) would be the right approach. This sounds extremely useful. If someone decided to persue this path, would it be possible to integrate the monitoring piece into zoneadmd? Since it's already started to manage the zone, I reckon it could send state changes and errors to the fault manager or an SNMP trap host. - Ryan -- UNIX Administrator http://prefetch.net ___ zones-discuss mailing list zones-discuss@opensolaris.org
