Re: [zones-discuss] minor code review for 6890415 6880288 (zoneadm.c, native brand)
On Mon 22 Feb 2010 at 10:52AM, Jerry Jelinek wrote: On 02/22/10 09:40, Frank Batschulat (Home) wrote: May I have 2 code reviewers for the following minor changes for: PSARC/2010/008 Remove zoneadm install sub-option -x nodataset 6880288 retire zoneadm install -x nodataset option 6890415 zoneadm install fails but returns 0 http://cr.opensolaris.org/~batschul/nodataset/ Frank, This looks good to me. To me as well, although I would be tempted to call temp_err something like cleanup_err. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6911329
On Thu 17 Dec 2009 at 01:58PM, Edward Pilatowicz wrote:
lgtm.
ed
On Thu, Dec 17, 2009 at 07:17:50PM +0100, Frank Batschulat (Home) wrote:
May I have 2 code reviewers for:
6911329 Incorrect code in kstat_delete causes panic
http://cr.opensolaris.org/~batschul/onnvkstat/
Description
A colleague was looking into a crash and the reason turned out to be a
NULL pointer dereference in kstat_delete():
kstat_delete(kstat_t *ksp)
{ kmutex_t *lp;
ekstat_t *e = (ekstat_t *)ksp;
zoneid_t zoneid = e-e_zone.zoneid;
kstat_zone_t *kz;
if (ksp == NULL)
return;
Note that there is a dereference of 'ksp' [via 'e'] before the check for
ksp being NULL.
unfortunately we don't have a dump/stacktrace anymore to inspect who
called kstat_delete(NULL) and why.
Do we really think that ksp being NULL is a invalid condition?
If it's invalid, then why not add an assertion, so we can root-cause.
Or has this if (ksp == NULL) been there forever and ever and there
are drivers abusing it?
I see a bunch of cmn_err's in kstat_create-- are there log files
from the machine which might indicate that there was a kstat_create
which returned NULL?
-dp
--
Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] quick bug fix webrev...
On Thu 19 Nov 2009 at 09:16PM, Edward Pilatowicz wrote: hey all, i need a review for the following bugfix: http://cr.opensolaris.org/~edp/onnv-zmount3/ 6901952 zoneadm fails with unable to determine default brand In the comment: zones - zone's. Is default brand actually a meaningful concept inside of a zone? That is to say, why aren't all calls to this routine guarded by: if (strcmp(zone_name, global) == 0) return (zonecfg_default_brand(brandname, rp_sz)); As is the case in zone_get_brand()? Maybe it doesn't matter... -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updated webrev...
On Tue 27 Oct 2009 at 10:58AM, Edward Pilatowicz wrote: hey all, i have an updated webrev for my previous fix: http://cr.opensolaris.org/~edp/onnv-zmount/ 6889379 zoneadm mount fails on opensolaris 6894901 zoneadmd can hang if fdetach() return EBUSY you'll notice i added 6894901 to the fix. i hit this issue while doing regression testing with the zones test suite. i've run the zones test suite with these changes and verified that there are no new regressions. zoneadm.c:5655: system's zoneadmd.c: 2065: so, do you want to back off at all here? maybe sleep for a tenth of a second? Even with the yield, this will suck a lot of cpu if we get stuck in this forever. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updated webrev...
On Tue 27 Oct 2009 at 07:03PM, Edward Pilatowicz wrote: the assumption is that we will never get stuck in this forever. if we do then this fix is broken and we need to redesign the exit mechanism. (i was debating just calling exit(0) instead of fdetach(), but iirc you spent a while coming up with the door thread exit dance, hence and i didn't want to change it too much.) Fair enough. my assumption is that in this case we want to exit as quickly as possible. By doing a yeild, i'm assuming that the doors thread in our process should get scheduled before we do and hopefully finish up it's work, there by allow us to exit (and not spinning too much). Thanks for filing the related bug. Did you catch this in action, with dtrace to know where that EBUSY is coming from? If we knew what was doing set_errno(EBUSY)... -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a new zone using latest OpenSolaris 2009.06
On Tue 25 Aug 2009 at 01:22PM, bastien sprenger wrote: Hi Kevin, It seams that I have the same issue when creating a zone on opensolaris, in august 2009 this time. r...@opensolaris:~# zoneadm list -cp 0:global:running:/::native:shared -:bastoszone:configured:/export/bastoszone::ipkg:shared r...@opensolaris:~# zoneadm -z bastoszone install A ZFS file system has been created for this zone. Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/). Image: Preparing at /export/bastoszone/root. Cache: Using /var/pkg/download. Sanity Check: Looking for 'entire' incorporation. ERROR: Unable to locate the incorporation 'ent...@0.5.11,5.11-0.111:20090601T075328Z' in the preferred publisher 'opensolaris.org'. Use -P to supply a publisher which contains this package. How and from where did you install this system? Can you please (in private email) attach me the output of 'pkg history -l'? (it will be large). I'm not familiar with this particular 'entire'-- it doesn't seem to actually exist in any of our repositories, which is odd. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Transfer from 'http://pkg.opensolaris.org/release' timed out: timed out.
On Mon 06 Jul 2009 at 02:28PM, Brian Leonard wrote: Hi, I'm just trying to raise awareness on this issue. Folks in the opensolaris-help forum are getting pretty upset because it has not been possible to install a zone for days. See: http://opensolaris.org/jive/thread.jspa?threadID=107149tstart=15 We've had a series of issues with our production infrastructure, some of which should rightly be blamed on me, since my second (third?) job is to run the pkg(5) infrastructure. The pkg(5) team is actively working on these issues. We made some changes on Thursday in response to the original issue the poster mentioned on July 2, and things seemed to be better. The initial problem was created by operator error on my part-- I thought I had applied a critical fix to a python module, but in fact had only done the dry run of the patch. This had the knock-on effect of reintroducing the horrible 408-errors-of-doom problem we've had in the past. For more, see http://defect.opensolaris.org/bz/show_bug.cgi?id=8903. Subsequent to that, we've hit a new round of issues, and we've only partially root caused them. This was all compounded by my absence over the holiday weekend. Finally, we know that people want offline zone installation. We've got a roadmap which points in that direction, and we're trying to get there. Apologies, -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] 2 line code review...
On Mon 15 Jun 2009 at 03:42PM, Edward Pilatowicz wrote: hey all, could i get a code review for this two line change: http://cr.opensolaris.org/~edp/onnv-bugs1/ 6850112 zonecfg verify should verify the native brand type Looks good. I assume that on SXCE the native brand verify is a no-op? -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] upgrading zone and /dev - /release part 2
On Thu 04 Jun 2009 at 06:04AM, Chris Josephes wrote: Okay, that worked. I eventually got the zone up and running, but I'll admit it was a little difference compared to my Solaris 10 experiences. I think I'll gradually adjust once I get a little more used to the IPS system. And hopefully, sparse zones will be available soon. If there were other negative differences, please let us know-- things like the sysidtool should be basically the same. Once the container is installed, the runtime inside is quite similar, although it's intentionally a lot more minimal. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a new zone using latest OpenSolaris 2009.06
On Thu 04 Jun 2009 at 06:21PM, Kevin Pan wrote: Hi, I have installed the latest OpenSolaris 2009.06 and tried to create a new zone. I have tried both installations on my local machine as well as launching a OpenSolaris 2009.06 instance on Amazon EC2. Both came up with something like this: --- ad...@computer:/zones# zoneadm -z testspeed install A ZFS file system has been created for this zone. Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/). Image: Preparing at /zones/testspeed/root. Sanity Check: Looking for 'entire' incorporation. ERROR: Unable to locate the incorporation 'ent...@0.5.11,5.11-0.111:20090514T145840Z' in the preferred publisher 'opensolaris.org'. Use -P to supply a publisher which contains this package. ad...@computer:/zones# --- Does anyone has any idea why? How can I resolve this problem? Thanks! Kevin, Yes- there's a bug in the metadata on the server. I have just this minute pushed a fix for this. Can you try again? First: $ pfexec pkg refresh Then go again. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] upgrading zone and /dev - /release part 2
On Wed 03 Jun 2009 at 04:19AM, Chris Josephes wrote: I'm trying to build a zone on a fresh install of 2009.06 and I'm seeing the exact same error. I'm using pkg.opensolaris.org/release as the authoritative repository, and it fails on the sanity check for the entire package. ERROR: Unable to locate the incorporation 'ent...@0.5.11,5.11-0.111:20090514T145840Z' in the preferred publisher 'opensolaris.org'. When I search the repository for 'entire' I see plenty of entries, but it doesn't list the full version numbers, so I can't tell if it's really listing the version that zoneadm expects to find. Chris, Bah. Sorry. We (inadvertantly) created a situation where the metadata in the repository is not really self-consistent with what's on the CDROM, due to the novel way we published the final release bits. Essentially, the global zone is trying to find a version of entire in the repository which matches what it has. But, there isn't one which exactly matches. So, the fix is to run: $ pfexec pkg image-update In your global zone (it should be reasonably quick because it will only update the 'entire' meta-package). Then reboot. Then, all should work. That worked for me in my test environment. If not, please let me know. And, my apologies :( I'm also going to see if we can do some publication magic to get the correct version of entire published into the repository, hopefully in the next 48 hours. This should correct the problem for most users. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] high values for zones size in os2008.11
On Thu 30 Apr 2009 at 08:29AM, solarg wrote: hello all, i have a machine with os2008.11 that serves as a web server, and has many zones installed. I'm surprised by the size of zones: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool/zones/catalogue2/ROOT/zbe 4.49G 17.9G 7.47G legacy rpool/zones/catalogue3/ROOT/zbe149M 17.9G 6.80G legacy rpool/zones/test-drupal/ROOT/zbe 511M 17.9G 5.21G legacy on another os2008.11 machine, i created a new zone, and don't notice these high values: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool/export/catalogue4 4.07M 16.1G21K /export/catalogue4 rpool/export/catalogue4/ROOT 4.05M 16.1G18K legacy rpool/export/catalogue4/ROOT/zbe 4.03M 16.1G 235M legacy what is the meaning of REFER? can i gain more space? thanks for help, Gerard, I can make a guess: I suspect that space in your zones is being consumed by data which is 'stuck' in zfs snapshots. Can you do a 'zfs list -t all'? You might have an automatic snapshot service turned on, or have manually made snapshots. Or you might be using zfs clones? It would be nice to see the output of: zfs list -t all -o name,used,refer,origin -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris10 brand project proposal
On Mon 27 Apr 2009 at 07:03PM, Jerry Jelinek wrote: Robert, Robert Milkowski wrote: +1 !!! Thanks for voting for this. Belatedly, a big +1. Jerry, if you have not already, I can take this to the OGB for creation. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
On Thu 23 Apr 2009 at 01:06PM, Ben Rockwood wrote: Jerry Jelinek wrote: Ben Rockwood wrote: One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. Ben, The sysevent service should not run in the ngz. This is delivered in a hollow pkg with svr4 pkging. You might take a look at my p2v webrev for opensolaris. ... Excellent! That explains things. I know that syseventd doesn't run in zones, but in the past I've seen SMF scripts simply exiting if it was in a ngz, I wasn't sure how this was handled. Well, it doesn't actually explain why you're in this situation. Jerry-- shouldn't it be the case that we don't even deliver this into the ipkg zone? I was surprised by Ben's mail initially because IPS support for variants should mean that the sysevent service is not delivered in the zone when installed: $ zonename global $ pkg search /var/svc/manifest/system/sysevent.xml INDEX ACTIONVALUE PACKAGE path file var/svc/manifest/system/sysevent.xml pkg:/sunw...@0.5.11-0.111 $ pkg contents -m SUNWcsd | grep sysevent.xml file 59577d5adb8f6609814cf693b79f80001ebe3b6c chash=86217745abacf6ada215c19c29b411567a3422e2 group=sys mode=0444 -opensolaris.zone=global ... -variant.opensolaris.zone=global So I'm perplexed how this service could wind up in the zone-- unless the variant isn't getting set properly in the image? Or perhaps the mixing of a very new version of SUNWipkg with older repository contents is causing this to not work right... I'm not certain. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
On Thu 23 Apr 2009 at 03:16PM, Ben Rockwood wrote:
Excellent! That explains things. I know that syseventd doesn't run in
zones, but in the past I've seen SMF scripts simply exiting if it was in
a ngz, I wasn't sure how this was handled.
Well, it doesn't actually explain why you're in this situation.
I missed you too Dan. Still got that charm.
...
My hunch at this point is that anything 98 or newer should be pain free,
but I think 101 (to align with 2008.11) is probly a safer bet.
So it turns out that you've stumbled upon a previously undiscovered
bug in our zone support in pkg(5). Thanks for finding this.
The summary is that variant-aware versions of SUNWipkg don't honor
the older opensolaris.zone={global|non-global} tags. The introduction
of variants altered those tags (in builds published since then) as
follows:
opensolaris.zone=global -- variant.opensolaris.zone=global
Normally this would be OK because we introduced variant support along
with publication of variant tags at the same time, IIRC in build 106,
when SPARC support came in.
However, we will eventually have to backpublish the current version of
SUNWipkg into the 'release' repo in order to allow folks running on
release to update to the next significant release version (2009.H1 as
it's being called). And it's this same mixing of old and new which is
causing you problems here.
If you run on 106+ all should be well. Bart is doing us a favor and
looking into how to fix this. In all likelihood we'll teach the
packaging client to recognize that opensolaris.zone=global is present,
but that variant.opensolaris.zone=global is missing, and to then
fill in what is missing.
I've filed http://defect.opensolaris.org/bz/show_bug.cgi?id=8392 to
cover this issue. If you monitor the status, it'll let you know when it
makes sense to pull a new version of the pkg-gate and try out the fix.
Thanks guys!
-dp
--
Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Update Grants, Merge BrandZ and Zones Communities
On Tue 10 Feb 2009 at 05:44PM, Steve Lawrence wrote: I vote +1 to all nominations, upgrades, and additions. Much thanks to Dan for tackling this. Sorry, I was busy and didn't have time to work on this. I believe we've reached the required votes, and I will forward to the OGB the results of this process. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Update Grants, Merge BrandZ and Zones Communities
(Credit to Alan Coopersmith and Liane-- from whom I've cribbed some of this) OGB election season is approaching again, so it's time to begin our annual review of Contributor Core Contributor grants for the Zones community. See BACKGROUND below for more background on this process. At this time I would also like to propose that we merge the BrandZ and Zones communities. These two activities are interrelated, and it's easiest if I start with the merger first. 1. PROPOSED BRANDZ COMMUNITY MERGER All contributor grants for the BrandZ community are due to expire this month. I would like to propose the merger of the BrandZ community into the Zones community at this time. This is in some ways reflective of the work done in the past two years by Jerry Jelinek to broaden the scope of the BrandZ infrastructure. Today, all zones are branded (even native ones). And the same team now owns the charter for both technologies. Having spoken to several of the core contributors of the zones community, the BrandZ community, and to an OGB member, I am at this time recommending that we utilize article 7.12 (Termination, see below) of the OpenSolaris Constitution, and allow all of the contributor grants in the BrandZ community to expire. This will terminate the community. The communities will forward to the OGB their recommendation that, under article 7.12, the BrandZ community's contents should be merged with the Zones community. We will ensure that web content related to BrandZ is not lost, and the brandz-discuss mailing list will continue on. That is to say, except for less bureaucratic overhead, everything will be the same as before. The zones community will take extend sponsorship to all projects sponsored by the BrandZ community. No specific changes to the project structure are proposed here, only a reparenting. For reference, article 7.12 states: 7.12. Termination. A Community Group is terminated by act of the OGB or by reduction of its named Core Contributors to a number less than three (3). Upon termination, the OGB may re-initiate the Community Group with a new set of Core Contributors or reassign the resources that were assigned to the Community Group, such as mailing lists, forums, and website information, to the at-large community or to some other Community Group of the OGB's choosing. (http://opensolaris.org/os/community/ogb/governance) 2. PROPOSED GRANTS The current grants for the zones and BrandZ communities are as follows. All grants are due to expire this month. login name StatusCommunity - allan Allan McKillopcore contrib zones annt Ann Togasaki core contrib zones dp Daniel Price core contrib zones comay David Comay core contrib zones gjelinek Jerry Jelinek core contrib zones mgerdtsMike Gerdts core contrib zones stevelaw Steve Lawrencecore contrib zones jeffv Jeff Victor contributor zones pcottenPenelope Cotten contributor zones richlowe Richard Lowe contributor zones edpEdward Pilatowicz core contrib brandz nilsn Nils Nieuwejaar core contrib brandz rabRussell Blainecore contrib brandz kucharsk William Kucharski core contrib brandz ahlAdam H. Leventhal contributor brandz jcmJerri-Ann Meyer contributor brandz hannkenJurgen Hannken-Illj contrib.brandz kirk Kirk Wellscontributor brandz Based on recent contributions, I would like to propose the following for the resultant merged community. This is a *proposal*. I would like input: login name StatusReason comay David Comay Emeritus former zones team lead, former CC dp Daniel Price Core Contrib Renew, still active gjelinek Jerry Jelinek Core Contrib Renew, still active stevelaw Steve LawrenceCore Contrib Renew, still active jeffv Jeff Victor Core Contrib Upgrade, Zones FAQ, Advocacy pcottenPenelope Cotten Core Contrib Upgrade, Docs author, Zones FAQ edpEd Pilatowicz Core Contrib New, Code cont, BrandZ core contrib flippedb Jordan VaughanCore Contrib New, Code contributions richlowe Richard Lowe Contributor Renew menno Menno Lageman Contributor New, Code contrib, work on Rsrc mgmt. mgerdtsMike Gerdts Contributor Former core contributor kucharsk William Kucharski Contributor New, BrandZ core contributor nilsn Nils Nieuwejaar Contributor New, BrandZ core contributor rabRussell BlaineContributor New, BrandZ core contributor ahlAdam H. Leventhal Contributor New, BrandZ contributor hannkenJurgen Hannken-Illje Contrib. New, BrandZ
Re: [zones-discuss] Update Grants, Merge BrandZ and Zones Communities
On Tue 10 Feb 2009 at 03:28PM, Glenn Faden wrote: I would like to nominate myself as a Core Contributor, having implemented several zones features (labeled zones, defrouter, cross-zone FIFOs, etc.). FYI, Trusted Extensions is also using branded zones at this time and has an active case to for a new brand called labeled. I am currently a Core Contributor in the Security Community, and active in the Zones community, I'll +1 that. -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] heads-up: zlogin fails if root has no password (nv105)
On Mon 05 Jan 2009 at 03:08PM, Steffen Weiberle wrote: For my test zones, I usually don't set a password via /etc/sysidcfg. Usually I don't configure ssh to allow root login, and the zones are configured with limited network services (secure by default), so I don't worry. With build 105 (the one with Crossbow integrated), all of a sudden zlogin fails if the zone does not have a root password. The error is an incorrect password type of message. # zlogin master [Connected to zone 'master' pts/4] Login incorrect So does logging in on the console. The error messages for this on the console are: Jan 5 15:04:33 master login: pam_unix_account: zlogin: empty password not allowed for account root from local host Jan 5 15:04:33 master login: login account failure: Permission denied I guess you are subject to the desires of the security folks here. I agree that it is mildly annoying. zlogin -S (failsafe) should still work, AFAIK. -dp -- Daniel Price - Solaris Kernel Engineering - d...@eng.sun.com - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone 'build': WARNING: bge0:1: no matching subnet found in netmasks(4) for 10.0.3.215; using default of 255.0.0.0.
On Mon 24 Nov 2008 at 08:06AM, Alexander Skwar wrote: Good morning! I just booted my OpenSolaris 2008.11 rc1b snv_101a system and started a non-global zone, which I have. --($ ~)-- pfexec zoneadm -z build boot zone 'build': WARNING: bge0:1: no matching subnet found in netmasks(4) for 10.0.3.215; using default of 255.0.0.0. Did you specify a netmask in your zone configuration? This is usually what people do. This is done like so: set address=10.0.3.215/24 Otherwise, the software has to infer what you want your netmask to be, and to do so it consults whatever name service provides your netmasks (in your case, sounds like files). -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
On Fri 03 Oct 2008 at 03:27PM, Nick Kew wrote: In normal operation, copy-on-write gives us this model for free. Does copy-on-write work across a zone_enter()? Yes. In the past, we've had some efforts to improve separation, based on worker children running under different user IDs. See for example the perchild MPM at apache.org. There's a lot of demand for perchild-like solutions, but no really satisfactory solution. My proposal is to provide an option whereby worker children perform a zone_enter before accepting connections or reading application- sensitive data. This of course assumes apache is started up in the root zone. Each zone will be the home for one or more virtualhost. It should be possible for zones to have different sizes (numbers of worker threads) and bandwidths (through crossbow), and other customisations. But the primary purpose - and I believe a huge selling-point - is the increased security of this virtualisation. Is there anywhere I can get the programmer documentation to get started on this work, beyond dabbling blindly with examples found on the 'net? Nick, I think this is an interesting idea, but I must caution you that zone_enter(2) isn't a public API, and using it correctly is truly non-trivial. One thing I don't really understand about your solution is what economy it achieves. That is to say, why not run an apache instance per-zone? If you like we can chat offline by phone sometime about this. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Upgrading a ipkg brand zone
On Wed 10 Sep 2008 at 12:24PM, Luca Morettoni wrote: I have installed on my laptop (under OpenSolaris 2008.05, snv_95) a ipkg brand zone (default for that operating system) and all work fine. Now I have updated the system to the snv_96, but my zones are on version snv_95, there are some special steps to keep zones updated or I follow the steps to update the global zone inside each zone? Luca, Try finding the root path to your zone, like this: # zoneadm list -vc ID NAME STATUS PATH BRANDIP 0 global running/ native shared - donutshopinstalled /zones/donutshop ipkg shared In this case it would be inside of /zones/donutshop, in /zones/donutshop/root Next, halt the zone, and from the global zone do (as root): # pkg -R /zones/donutshop/root image-update It should move things forward for you. Obviously this is sort of experimental at the moment, and there are some issues. In the future, things will upgrade in-sync with the global zone. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [osol-discuss] solaris 8 container installation failed
On Fri 08 Aug 2008 at 11:13AM, Edward Pilatowicz wrote: [Thu Aug 7 23:59:44 EDT 2008] Installing: This may take several minutes... [Thu Aug 7 23:59:44 EDT 2008] cd /zones/solaris8/root [Thu Aug 7 23:59:44 EDT 2008] do_flar /engr.flar uncompress: stdin: corrupt input This code changed recently, and I guess there's a bug. My suggestion for now would be to use 'flar split' to unpack your archive by hand, then use the '-d' option to install the zone from the resulting directory of files. Make sure to do the unpack as root so that file permissions are correct. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zoneadm confusion
On Thu 10 Jul 2008 at 02:42AM, Konstantin Gremliza wrote: Ok. I wrote a dtrace script to monitor zone states. The resulting automata is in the attachment. In the state down, we should still have a zsched (ps), but we should not have any mounted filesystems, which is true (df). Nicely done! This is very well organized. There's more info on the different states in the big comment at the top of: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/zone.c -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] need input for zone update on attach
On Wed 18 Jun 2008 at 10:36PM, Mike Gerdts wrote: On Wed, Jun 18, 2008 at 8:47 AM, Steffen Weiberle [EMAIL PROTECTED] wrote: I am not sure I have an opinion yet, as I am not sure what major downgrade means. If that would allow you detach the zone from the new system and re-attach on the original, I can see a benefit. (The inability to attach a zone on its original system is my biggest concern with the upgrade on attach.) The combination of update on attach plus zones on ZFS should make this problem be one that isn't too scary. I imagine the following as being standard practice. zfs snapshot zones/[EMAIL PROTECTED] zoneadm -z $zone attach -u if [ $? != 0 ] ; then zfs rollback zones/[EMAIL PROTECTED] fi Of course, it would be nice if zoneadm would just do this on its own. Yeah, we thought that up a couple of weeks ago and there's an RFE filed. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] can time be different in local zone?
On Thu 12 Jun 2008 at 05:54PM, Sanjay Akula wrote: Hi Users, I just have one question is it possible to have different time in local zone with out effecting the global zone time? Pl. advise me on this.. The time zone can be different; however you cannot independently set the time. We did a prototype of this, but have not productized it. Can you tell us anything about the usage scenario for this? -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ipkg branded zones getting different bits then the GZ ?
On Tue 10 Jun 2008 at 08:18PM, isaac wrote: Ran into an interesting observation at a tradeshow today, where OpenSolaris 2008.05 has been installed. Then proceeded to create a zone. The installation phase of the zone reached out to pkg.opensolaris.org - and as part of that process we noticed that the NGZ's /etc/motd reports snv_90 (that is likely due to newer bits being available) - and yet 'uname' in NGZ reports the expected (snv_86). Isaac, You may wish to review http://blogs.sun.com/dp/a_field_guide_to_zones In the case you are in, you've got a zone which is uprev of the global zone-- a case you should avoid, we certainly can't guarantee that this will work. The simplest solution for now is to simply upgrade the global zone to match. In the future (maybe for November?) we will work harder to keep these in sync. also noticed the brand for the zone appears as 'ipkg' and not 'native'. This is temporary, and in future releases will change. cool, but how are we dealing with newer bits not necessarily deviating from the kernel version installed? We will eventually have code in place to keep things in sync with each other. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ipkg branded zones getting different bits then the GZ ?
On Wed 11 Jun 2008 at 10:07AM, Dan Price wrote: On Tue 10 Jun 2008 at 08:18PM, isaac wrote: Ran into an interesting observation at a tradeshow today, where OpenSolaris 2008.05 has been installed. Then proceeded to create a zone. The installation phase of the zone reached out to pkg.opensolaris.org - and as part of that process we noticed that the NGZ's /etc/motd reports snv_90 (that is likely due to newer bits being available) - and yet 'uname' in NGZ reports the expected (snv_86). Isaac, You may wish to review http://blogs.sun.com/dp/a_field_guide_to_zones Sorry, that's: http://blogs.sun.com/dp/entry/a_field_guide_to_zones -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] rlogin service in zone
On Thu 01 May 2008 at 09:43PM, Nitin Ramannavar wrote: Hi Folks, I'm trying to enable the rlogin within a local zone. However I'm not able to enable the rlogin service because the sysidtool is not getting started correctly. Any clue?? bash-3.2# svcs -x svc:/system/sysidtool:net (sysidtool) State: offline since Wed Apr 30 03:55:57 2008 Reason: Start method is running. See: http://sun.com/msg/SMF-8000-C4 See: sysidtool(1M) See: /var/svc/log/system-sysidtool:net.log Impact: 18 dependent services are not running. (Use -v for list.) Is this a newly installed zone? You'll want to do 'zlogin -C zonename' to log into the zone console, then proceed with setup by answering the questions presented. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] noteworthy: PSARC/2008/265 (pfiles and TLI)
It's hard to keep up with everything happening in the OpenSolaris universe-- for example, I missed this great PSARC case written by Peter Memishian: http://www.opensolaris.org/os/community/arc/caselog/2008/265/ The upshot of this is that pfiles(1) is soon going to be a lot more useful when applied to processes which use TLI-- a good example is rpcbind-- for which you'll now be able to see local and remote endpoints for the various RPC things it is doing. I bring this up on zones-discuss because Peter notes in the case that he was specifically motivated to do this work in order to benefit users of zones. Thanks Peter! -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Sparse Full
On Wed 02 Apr 2008 at 09:06PM, Morris Hooten wrote: Is there a way to convert a sparse zone to root or just remove inherited lofs to GZ? I have a sparse zone I'd like to have it's own /usr Morris, At present there is no way to convert. But this is a use case I will keep in mind as we design our next generation solution. If other folks need this, please pipe up so we can gauge the importance. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Lost network connectivity and NIC recognition
On Tue 18 Mar 2008 at 05:17PM, Anne Moore wrote: You're wrong here and you were wrong about the migration. Why can't you accept that!? You should be asking me HOW I did the entire thing so successfully than saying it can't be done. You should learn to WORK with the public engineers, not against them. Anne, I'm the engineering team lead for zones; maybe we can talk about your migration technique? We have a lot of customers asking for either technical or operational solutions to problems like this. As you already know, we have 'zoneadm attach' and 'zoneadm detach' commands which are primitives for implementing various forms of migration; these commands include an automatic patch and package revision checker which attempts to validate that the software running on old and new systems matches. It is certainly possible to circumvent this checking, for example using the -F flag to attach. In general I caution folks that migrating zones between systems with differing patch levels may have unexpected results, using the currently available attach/detach support. This is because you could potentially end up in a situation in which configuration files or binaries wind up fatally out of sync with what is in the global zone. This is true even with a sparse zone. This is especially problematic because when something does go wrong with mismatched binaries, it can be incredibly hard to debug. In a future Solaris 10 update release, we're going to add support for resynchronizing the zone with the global zone during a migration (attach -u), thanks to some really hard work done by Jerry Jelinek. You can read the design documentation and discussion for this feature here: http://opensolaris.org/os/community/arc/caselog/2007/621/mail I guess what I'd say is that doing zone migrations without a resynchronization tool is sort of like harrassing your dog (as I did as a very small child). The first ten times you do it, the dog might not bite you. But that doesn't mean it's safe to do (and I have the scar to prove it). I bash people who bash me, period. Do you want me to cower in a corner an cry when someone bashes me!? Have you lost all your sense of dignity and courage?? In my view, this list is a no bashing zone (no pun intended). Let's all of us please keep the tone as civil as possible. Many thanks, -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] bug? zone wont create device files during boot
On Fri 02 Nov 2007 at 07:23AM, Jerry Jelinek wrote: It sounds like you are hitting the following known bug: 6608977 Can't add device to non-global zone in S10 update 4 It looks like this is fixed in patch 125914-01 for x86 and patch 127111-03 for sparc, although 127111-03 isn't quite released yet. I just looked this up-- it appears this patch (127111-03) is now available. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] bug? zone wont create device files during boot
On Mon 01 Oct 2007 at 11:28AM, Dan Price wrote: So, stay tuned. We've been sorting this out for about a week now, and are at work on getting a patch out as fast as possible. For contract customers, filing an escalation on bug 6608977 should get you access to binary relief (in the form of an IDR) as soon as it is available. As you may know, there is a huge amount of new zones functionality in S10 8/07, so this regression is particularly humbling. Again, please accept our apologies. Just as a followup to this thread (I sent another mail to the alias as well), I wanted to give a status update. It appears that this defect can now be corrected by applying 127111-03 (SPARC) or 125914-01 (x86). As I mentioned before, we've got some changes coming in our test suites to make sure we don't get hit by bugs like this in the future. Thanks again for your patience. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] RFC on introducing getzoneidbyname(9f)....
On Mon 12 Nov 2007 at 01:54PM, Darren Reed wrote: Looking in usr/src/uts/common/os/zone.c, there are is a number of functions that have the words Public interface before them, such as: /* * Public function to retrieve the zone status. The zone status may * change after it is retrieved. */ zone_status_t zone_status_get(zone_t *zone) ... However doing a man zone_status_get returns nothing, so it would appear that it isn't completely public. I think the author likely was a little imprecise, and meant not static-- i.e. callable from other parts of the kernel. In light of there being a relative lack of public functions in the kernel to deal with zone names and id's, I'd like to propose providing an implementation of getzoneidbyname() and getzonenamebyid() for the kernel that mirrors the behaviour of those found in libc today. So to summarise, I'd like to provide getzoneidbyname(9f) and getzonenamebyid(9f) that have the same interface as getzoneidbyname(3c) and getzonenamebyid(3c). Comments? Is there a proposed consumer? I assume ip filter? Or, putting it another way, what does a zone name--id mapping facility provide that you need? This should help to evaluate the proposal. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] apache2 ignoring capped-memory
On Sun 04 Nov 2007 at 07:29PM, Mike Gerdts wrote: ZONEIDNPROC SWAP RSS MEMORY TIME CPU ZONE 5 37 270M 121M 9.5% 0:01:12 2.1% www 4 35 330M 80M 6.3% 0:03:58 3.8% helix 0 49 68M 93M 7.3% 0:37:10 0.8% global 3 28 37M 53M 4.1% 0:23:21 0.7% icecast1 so according to prstat apache is still using about 1g of swap+memory and more RSS that the zones is? In the not too distant past, prstat would naively sum the RSS of all the processes in the zone and say that was the RSS for the zone. This can gave ridiculous results when you had something like oracle with an hundreds of processes mapping an SGA (shared memory segment) that was many gigabytes in size. I've seen large systems say that tens of terabytes of RAM were in use when the systems (obviously) had less than a terabyte of RAM. Right-- and thankfully, in the build he'd running, that isn't the case any more. You're seeing an accurate measure of RSS. At least from this measurement, this looks like an OK system. Your RSS is well below the total amount of RAM you said the system has... -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] bug? zone wont create device files during boot
On Tue 02 Oct 2007 at 07:35AM, Konstantin Gremliza wrote: Someone earlier stated that this was also broken in SXDE-- as far as I know that is *not* the case. One of the reasons this has been a troublesome area is that in Nevada the /dev zones implementation is radically different from S10, due to the existence of the devnames project in Nevada. Hence the S10 and Nevada code is pretty in this area. -dp Before I posted this to [zone-discuss] I tried again on SXDE 09/07, and the same problem occured. Adding a device match will not create any device files in ZONEPATH/dev. Konstantin, we'll go back and retest SXDE 9/07, although at present we don't have a bug for this problem open against SXDE. As I said, the code is basically completely different in that area between SXDE and S10, so it would have to be a new and different bug. My desktop is a SPARC box running build 72 (which AFAIK is SXDE 9/07) and I don't see this there; this is an example of adding, then removing a pseudo device in a basic test: # uname -a SunOS snowdog 5.11 snv_72 sun4u sparc SUNW,A70 # ls -l /aux/foo/root/dev/lockstat /aux/foo/root/dev/lockstat: No such file or directory # zonecfg -z foo 'add device; set match=/dev/lockstat; end' # zoneadm -z foo reboot # ls -l /aux/foo/root/dev/lockstat crw-r--r-- 1 root sys 89, 0 Oct 3 02:55 /aux/foo/root/dev/lockstat # zonecfg -z foo 'remove device match=/dev/lockstat' # zoneadm -z foo reboot # ls -l /aux/foo/root/dev/lockstat /aux/foo/root/dev/lockstat: No such file or directory (Please note that I'm not advising that anyone add /dev/lockstat to their zone; I simply used it as a test case). Perhaps you could post your SXDE test case? -dp - Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] bug? zone wont create device files during boot
On Mon 01 Oct 2007 at 01:14PM, John Chase wrote: This has just been escalated as a P1 bug in 8/07. Indeed. And please accept our apologies that this bug slipped out. This was a case where a late performance fix wound up impacting correctness. We're still assessing why our test suite (and our engineering) did not catch this problem. S10 8/07 is also supposed to have a fix for device removal from zones. I authored the original fix. In the process of that fix being ported back to Solaris 10, it was merged with BrandZ code, and at that point that fix *also* became broken. We're working on a fix for that, as well. So, stay tuned. We've been sorting this out for about a week now, and are at work on getting a patch out as fast as possible. For contract customers, filing an escalation on bug 6608977 should get you access to binary relief (in the form of an IDR) as soon as it is available. As you may know, there is a huge amount of new zones functionality in S10 8/07, so this regression is particularly humbling. Again, please accept our apologies. Someone earlier stated that this was also broken in SXDE-- as far as I know that is *not* the case. One of the reasons this has been a troublesome area is that in Nevada the /dev zones implementation is radically different from S10, due to the existence of the devnames project in Nevada. Hence the S10 and Nevada code is pretty in this area. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ps -Z is broken
On Sat 29 Sep 2007 at 11:44AM, Peter Tribble wrote: OK, I've seen Andy's reply in the pgrep thread, so basically I believe we should just print out the whole zone name. In other words, %8.8s becomes %8s, and if it's short it will line up like it does at the moment. If it's long, it will be ugly but accurate. I agree. I should also fix the zone header so that everything will line up properly if the zone names are short enough. Which then leads to the question: how should the ZONE header line up? At the moment it's in the middle of its column with 2 spaces either side - which seems odd given that most headers are right-justified. I'm tempted to push this to the right as well. Weird, I thought it *was* right justified in the column? Maybe you can post an example of what you mean; I see this: ZONE PID TTY TIME CMD global 9056 pts/8 0:00 vim global 9072 pts/8 0:00 ps global 9055 pts/8 0:00 sh And to me it looks right justified, since the PID column is 5 digits in width. And should the username truncation problem be addressed as well? (And if so, done as part of this or separately?) I presume this is the web page mentioned earlier: Well, I don't know the answer, I'm not very knowledgable about user names. My suggestion would be to tackle the zone problem first, since it is small and uncontroversial (to me, anyway). As you point out, the output is not very useful, so I can't imagine anyone would have built anything which depends upon it. I'm happy to sponsor a fix, or can develop one when I have the chance. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] unable to rsh into zone2
On Thu 27 Sep 2007 at 08:24AM, James Carlson wrote: [EMAIL PROTECTED] writes: Anyone know how to start the restarter? You don't need to, and doing it wouldn't help. Instead, you need to use zlogin -C zone2 to connect to the zone's console and answer the questions that sysidtool is asking. Those questions (such as the root password and default time zone) are what's blocking it from booting up. Once you've done that, it'll boot up correctly. Alternatively, you can make sure that you use a sysidcfg file when you install the zone. There are references to this in the documentation ... We should really detect this case (the unconfigured zone, I mean) and print something out when you boot it up... perhaps: # zoneadm -z myzone boot Notice: Zone appears to have no sysid configuration. Log onto zone console to complete configuration before using the zone. (ok, needs wordsmithing need on the message, I realize) -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how long would it take to install a zone on Sun
On Tue 18 Sep 2007 at 11:06PM, sunnie wrote: After reading some material about zoneadm clone, it seems to me that such a fast zone creation requires the template zone to be on a zfs file system. However, if not, anything else can help speed up installing zone? Especially, at present, my SUNOS only have a global zone. By default /opt will be *copied* from the global zone. If you want it to be sparse instead (which means it will be a loopback, read-only filesystem) then add an inherit-pkg-dir entry for /opt. This will usually significantly speed up installation, especially if you have a lot of stuff in /opt. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how long would it take to install a zone on Sun
On Wed 19 Sep 2007 at 10:21AM, Steffen Weiberle wrote: Hi Dick, Dick Davies wrote: On 19/09/2007, Steffen Weiberle [EMAIL PROTECTED] wrote: On ZFS, with Nevada, a snapshot and then clone is created, so it is very fast. That's also the case in Solaris 10 update 4, I believe. That is not my experience, and I just tried it on build 12 (not GA version), and it did not create a ZFS snapshot nor a clone of Correct. Because we can't upgrade zones living on zfs filesystems (yet) we left this feature out of S10 U4. It is, however, in Nevada. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] list of default /dev nodes in non-global zones
On Wed 19 Sep 2007 at 06:05PM, Sebastien Roy wrote: I'm working on adding a new service which runs in a non-global zone, and which uses a control device in /dev. How do I arrange for this /dev node to appear in non-global zones? Check out /usr/lib/brand/native/platform.xml, which defines which devices should appear in native brand non-global zones. You should also think about which privileges your device needs, and whether zones have those privs (or don't, as appropriate). Any pseudo device going into a zone should also get a very thorough security evaluation. We can help-- feel free to follow up here, or offline. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Correct procedure to remove a ZFS file system from a non-global zone
On Fri 07 Sep 2007 at 04:08PM, Dan Price wrote: On Fri 07 Sep 2007 at 11:53AM, Ril wrote: I posted this query to the ZFS discussion forum, but got no replies -- perhaps this is more of question about zones than zfs: I followed the procedure to add a ZFS dataset to a non-global, whole-root zone as a delegated dataset as described in the ZFS Admin Guide, page 129. What is the proper way to remove it? I tried the following: From the global zone: 1) halt the zone 2) use zonecfg to remove the dataset 3) boot the zone When I logged back into the zone, the mount point was still present, but now under /, but the files were gone, and they weren't present in the pool on the global zone, either. Is this the correct procedure to remove a ZFS file system from a non-global zone? Is there anyway to do this without losing the data in the file system? I don't think your data is actually gone. When zfs filesystems get handed out to non-global zones, a special bit is set on the filesystem, in the form of a zfs property called zoned. Here is what the man page says: And by the man page I mean, zfs(1m). -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting the time in a Zone (or Container)
On Fri 17 Aug 2007 at 10:36AM, Rayson Ho wrote: Timewarp Zones will eventually be in a future version of Solaris: http://blogs.sun.com/dank/entry/28_days_later http://blogs.sun.com/dank/entry/the_semantics_of_time_independent http://blogs.sun.com/dank/entry/back_to_the_future_timewarp Rayson Actually we haven't committed to doing so: Dan K. (our summer intern) did a nice prototype of this functionality and I think we're now at the point of understanding the problem a lot more thoroughly than we did a couple of months ago. We'd like to develop a sense of how important this is: we've heard this request from a few customers at times, but we'd like to understand the use case. Duncan, can you tell us more about what you're up to? -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Wiki
On Wed 08 Aug 2007 at 05:31PM, Andrew Dishong wrote: I have created a Containers Wiki, please take a look and contribute often. Please read the policies regarding posting material, thanks andy That's interesting, but I think it would be nice if you talked to the community *first* before doing so. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [brandz-discuss] Creating a Virtualization Community Group
On Tue 07 Aug 2007 at 04:29PM, Nils Nieuwejaar wrote: On Tue 08/07/07 at 16:18 PM, [EMAIL PROTECTED] wrote: Discussion on the OGB-discuss list regarding creating a LDOM (Logical Domain) Community, has again brought up the question of whether to form a combined virtualization community group. (With XEN, LDOM, and Zones all being working groups in the CG, and individual projects likely falling within the scope of a working group.). To do this we would need buy-in from the existing XEN and Zones community groups, as it would be relatively pointless to do this without these them. I am not aware of any major reasons that someone might be opposed to this. Please feel free to either voice your support or opposition. (Also, I think it would add some weight to the proposal if community group leaders and core contributers are willing to sponsor this change.) I think we went through this a couple of months ago, and all the interested parties were fine with that idea. I don't remember any official word as to why the idea was scuttled. Yeah, me too. To respond to Ellard's point: Communities can host multiple mailing lists. So zones-discuss will stay zones-discuss, etc. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [brandz-discuss] Creating a Virtualization Community Group
On Tue 07 Aug 2007 at 04:14PM, Tony Kay wrote: Hi Russ On 7 Aug 2007, at 15:14, Russ Petruzzelli wrote: [EMAIL PROTECTED] often discusses virtualization in a general sense. I often see people bring up questions regarding comparing different virtualization implementations. It is at this point an internal alias and I don't see this changing in the short term. I think it wouldn't be the ideal community for this, though some of its members would probably be interested in joining an additional alias for non VMware/Sun discussions. A Solaris on VMWare project might (might, after due consideration) be an appropriate project to fall under for the V12N community, but no one has (as far as I know) stepped forward to create such a project. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zonecfg question
On Thu 02 Aug 2007 at 10:35AM, Yanakiev, Vladimir wrote: Yes, John, that's my understanding too - zonecfg is supposed delete both the entry in the index file, and the xml. But, somehow we ended with this awkward status. It makes sense to me if zonecfg detects such status, to send one extra Status missing - are you sure to delete?-type of message, and remove the xml... It looks like there is no logic in the code of zonecfg for the cases when there is trouble with the index file... Hi guys, I did some cleanup in this area a while back; there were a number of cases where this could wind up happening. Forgive me for coming in late to the thread but what revision of Solaris are you running? The changes I made were introduced into Nevada build 24 and appear in Solaris 10 11/06 (sometimes called update 3). PSARC 2005/485 Zone Rename 4963365 zonecfg is unhelpful if /etc/zones not present 4971371 zonecfg should be more paranoid when saving a zone for the first time 5022506 RFE: ability to rename zones 6231612 zonecfg messaging should be improved. 6305400 when zone metadata gets confused, removing configured zones can fail 6318536 zonecfg sometimes seen spinning during certain STC test cases 6321858 zonecfg tab completion could complete slightly more In particular, the fix for 6305400 should have helped this situation. The dance to make this all work right is surprisingly complicated. Check out zonecfg_destroy() in libzonecfg:libzonecfg.c and putzoneent() in libzonecfg:getzoneent.c if you are interested. In the future we'll probably move the config into SMF and (I hope) utilize the index file purely as a cache for information stored in the backend (for speed) or just drop it altogether. Having multiple places that this information is stored is very irritating to implement correctly. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can the network interface of a local zone geta dynamic ipv4 address?
On Fri 03 Aug 2007 at 12:39PM, Lu, Baolu wrote: Thanks for reply. I use snv_68 32 bits. The zonecfg doesn't support set ip-type command. Which build is this feature available since on? Since Build 57. Are you sure it isn't there? Try this: zonecfg help set|grep ip You should get (global)ip-type If not, then I'm not sure what is up. The other thing I forgot to mention is that IP instances needs you to have a physical network connection (or VLAN) which you can assign to the zone. See also this thread, which has some more good info about IP Instances: http://www.opensolaris.org/jive/thread.jspa?messageID=102102 I also realize that this isn't a great answer overall-- that it would be nice if this just worked. We'll keep trying to improve things in this space. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Running zonename command in an alternate root
On Thu 26 Jul 2007 at 05:04PM, James Carlson wrote:
Here's a code snippet :
ZONECMD=${PKG_INSTALL_ROOT}/usr/bin/zonename
That's the broken part. That should be just:
ZONECMD=/usr/bin/zonename
I'm lacking context here, slightly, but...
Isn't it also broken to be calling /usr/bin/zonename? /sbin/zonename
is shipped in SUNWcsr, and /usr/bin/zonename is only in SUNWzoneu.
This is a bug, and one we should fix, but it's the behavior we've got.
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone info question
On Fri 06 Jul 2007 at 12:15PM, Jerry Jelinek wrote: Russ Petruzzelli wrote: In a script I'd like to run prtdiag if I am in a global zone. Is there a zoneadm command to tell me what kind of zone I'm in? It's not jumping out at me in the zoneadm help. eg: if [[ globalzone == true ]]; then OR is there a way to get this to run in a zone?... /usr/platform/SUNW,Ultra-80/sbin/prtdiag -v You could try this: if [ `/usr/bin/zonename` = global ]; then Slightly better is to run /sbin/zonename, since that is available even if root isn't mounted and even if zones package (SUNWzoneu) is not installed. (It's a bug that /usr/bin/zonename isn't delivered by SUNWcsu, but we haven't got around to fixing it yet). -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Setting up a testing environment for a P2P application
On Fri 06 Jul 2007 at 01:10PM, Jeff Victor wrote: - We are planning to test 1000 nodes (=containers) on a 2 GB RAM Athlon Dual Core 4.2 GHz machine. Is that possible? I'll make a stronger statement than JeffS: a Solaris container requires at least 20MB of RAM to boot and start up even the most basic services. Running all of them *simultaneously* is unlikely to work: the system would be paging to disk all of the time. RAM is definitely going to be a big issue. There's also the fact that JVMs tend to create quite a lot of threads. Some of the java instances on my machine have 25 threads. 25*1000 = 25000, which is doable, but a lot. Remember that each of those threads has a stack. If each stack is 16K (pretty conservative) then that's 400MB of java thread stacks alone-- never mind the heap space consumption. You might be able to limit that with JVM options, I don't know. - Each container should be a sparse zone that contains no application but a JRE. How do I create one of these? To expand on what Jeff Savit said: You really want to minimize your zone using SMF. Turn off inetd and most other system services. Use 'svcs -p' to spot the ones which you don't want. You might want to keep nscd if your p2p app does a lot of name service lookups, but most other daemons can go: cron, rpcbind (probably), automountd (unless using NFS), sac, syslogd, sshd, sendmail. You'll wind up with various parts of the system not working, but your memory footprint will really shrink. Once you have a very minimized zone, then you can clone lots of copies of it. If you are running Solaris Nevada, and using ZFS to store your zones, zones will use zfs cloning to do this very rapidly. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [perf-discuss] Poor zone performance in small servers
On Tue 19 Jun 2007 at 09:37PM, Luke Schwab wrote: Hi, I have recently been running performance tests with zones on several Sun servers. (280's and 880's), 2 CPU and 8CPUs respectively. On my 280 servers (2CPU machines), I installed and booted 3 zones and I get poor performance on across the network (400Mbps). I only transfer data at 80% of what I can in the global zone with no zones installed or booted (where I measured 550Mbps). That is a 20% difference in performance. I tested with the opensource tool called IPERF. I originally thought that zones were causing my problems so I decided to move to another type of hardware, a V880 (8 CPU) machine. When I ran my performance tests again with 3 zones installed and booted I saw 1% overhead in the network compared to running in the global zone with no zones installed or booted. Both of the 880 tests ran around 860 Mbps throughput with less then 1% difference between several scripted tests. Can anyone explain why I see this? Both servers have gigabit NICs installed. The only thing I can think of is that the backplane on the servers in a bottleneck for the small 280 servers. But how could this (or something else in the kernel space) be causing the symptoms I see above? I don't know offhand-- but could you please repost this CC'ing both lists? Otherwise we'll fail to have one conversation. Alternatively, responders, please follow up to this mail, which CC's both lists. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Memory limits for zones?
On Mon 18 Jun 2007 at 01:56PM, [EMAIL PROTECTED] wrote: Can someone tell me when memory limits will be supported in zones in Solaris 10? I'm looking for when the new zone resource management was or will be made available. Specify the memory limits for the zone my-zone. zonecfg:my-zone* add capped-memory* zonecfg:my-zone:capped-memory* set physical=50m* zonecfg:my-zone:capped-memory* set swap=100m* zonecfg:my-zone:capped-memory* set locked=30m* zonecfg:my-zone:capped-memory* end There will be an S10 update late this summer-- it'll be in that. It's also all in Nevada today. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] lofi devices broken after patching
On Mon 18 Jun 2007 at 12:52PM, Ron Halstead wrote: On Friday, June 15, 07, I patched the global zone on a machine with 2 local zones. The global zone has 4 file systems connected (but not mounted) from a 3320 storage array. Using lofiadm -a, i created 4 devices which I imported to the local zones - 2 to each zone. I then mounted the 4 file systems. After patching and rebooting the global zone, the imported lofi devices would not mount. The error messages was mount: /dev/lofi/1 is not this fstype. The same error held for the other 3 devices. ls -l /dev/*lofi/* in the global zone showed the devices present. I reran the lofiadm -a command and the devices were recreated, starting, again, with /dev/lofi/1 and not 5 which I expected. I was not specifying the disk device (c5todos0) and lofiadm creates them sequentially. When all lofi devices were recreated, I ran mount -a in the local zones and voila, the file systems mounted. I suspect a bug in one of the applied patches. I have submitted a bug report (my case # 4106) but I'm hoping someone has seen this and can lead me to the fix (short of running lofiadm -a every time the global zone boots). Thanks in advance - Ron I may be confused, but: the lofiadm man page says: Associations are not persistant across reboots. A script can be used to re-establish them if required. Do you have such a script? -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] FSS question
On Thu 17 May 2007 at 06:28PM, Ramesh Mudradi wrote: Hi I have a non-global zone binded to a pool with pset.min=4 and pset.max=16. I am running the script to flog the cpu of nonglobal zone from http://www.brendangregg.com/Zones/zoneflogcpu Before running the script, the non-global zone had 11 cpu shares assigned to it. Once the script started loading the CPU, I was expecting local zone to have max no. of cPU shares it can have . But though the load is increasing, the local zone is not getting its share. Any idea whats going on here ? Appreciate any pointers. bash-3.00# poolstat pset id pool size used load 1 mpk-uc-sparc1-z1 11 0.00 1635 0 pool_default 8 0.00 0.01 2 mpk-uc-sparc1-z2 13 0.00 0.00 bash-3.00# Is poold running? $ pgrep -lf pool 16289 /usr/lib/pool/poold -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Default RM controls for Containers?
On Thu 10 May 2007 at 04:21PM, Jerry Jelinek wrote: of the other controls is trickier although I think Dan's idea of scaling these based on the system makes it easier. We might also want to think about scaling based on the number of running zones. Another way to look at it (and I think what you are saying) would be to broaden the notion of shares a bit to include more of the system resources-- for example, memory. What's tough there, though, is that our notion of shares today represent an entitlement, and the case of memory, we're talking about a cap on utilization. I think fundamentally we hear from two camps: those who want to proportionally partition whatever resources are available, and those who want to see the system as virtual 512MB Ultra-2's or virtual 1GB, 1ghz PCs. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] sol10u3 resulting local zones no syslog or nfs
On Wed 09 May 2007 at 09:55AM, Stephen Hahn wrote: * Michael Barrett [EMAIL PROTECTED] [2007-05-09 08:43]: Just your normal stuff but no nfs or syslog. I do see that sysidtool:net is offline. I'm guessing this is my issue. svc:/system/sysidtool:net (sysidtool) State: offline since Thu May 03 06:39:14 2007 Reason: Start method is running. See: http://sun.com/msg/SMF-8000-C4 See: sysidtool(1M) See: /var/svc/log/system-sysidtool:net.log Impact: 24 dependent services are not running. (Use -v for list.) Nothing exciting in that log file. Usually this output means that the sysid tools are waiting for user input on the (zone) console (which is why they have infinite timeouts): $ svcprop -p start sysidtool:net start/exec astring /lib/svc/method/sysidtool-net start/timeout_seconds count 0 start/type astring method You know, we've seen this come up many times. I was wondering if anyone has any suggestions about how we could clue users in about this problem? Is there any way to provide greater diagnosis? Is there some way that this service could publish a hint about itself? Or something else we should do? Should zlogin print a warning when it logs you in on non-console? We could do something like... # zlogin myzone [Connected to zone 'cuphead' pts/4] [WARNING: Zone lacks system identity. Log into the console to complete configuraion] Or something else? I'm open to any and all suggestions. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Query urgent : To restrict the no of processes in a zone]
On Tue 08 May 2007 at 12:38PM, Nagaprasanna A wrote: 3) Now Cu comes back with the below query : My requirement is the ability to restrict the total number of processes per zone(as per details in your link). When will the above be implemented in Solaris 10 ? zone.max-lwps limits the number of total threads (or lwps) in the zone, and therefore also places an upper bounds on the number of processes, since every process has at least one thread. Beyond that, we're not currently planning to do this-- we're busy on other tasks. If you want to get in touch with us about more details about your customer, feel free to mail me privately. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] iscsi on zone
On Tue 17 Apr 2007 at 02:50PM, cedric briner wrote: nevada build: 61 hello the list, can we issue this commands inside a zone: - iscsiadm - devfs i iscsi? Since I'm trying to build up a cheap and reliable *san* based on zfs, iscsi nfs. When I try the follow: #iscsiadm list target iscsiadm: Unknown error iscsiadm: Unable to complete operation Cedric, As far as I know, at this time you can't have a zone be an independent iSCSI initiator. However, you can connect to the target of your choice in the global zone and then add that as a device to your zone with the add device command in zonecfg(1m). In this regard, iSCSI is just the same as Fibre Channel or locally attached disk. One problem with having a zone be able to import (or create) raw devices and then mount filesystems atop them is that it usually not too hard to scribble bad data onto the device and then get the filesystem to panic (the whole machine). That said, we think that in some environments this will be desired. I had a conversation with some of the iSCSI engineers a couple of weeks ago on this topic, so we're only really just starting to think about this. If you (or others on the list with a similar need) could follow up (privately if you want) with a little more detail about what you are trying to do, and how this fits into your business or project, I can get you a bug filed, and take it to the iSCSI team. To the best of my knowledge you are the first person to ask for this feature, although we do know it's an issue we'll need to solve eventually. Thanks, -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones on NFS
On Tue 17 Apr 2007 at 09:32PM, Jason King wrote: It sounds like (at least based on the description) that the 'Filesystem driven device naming' project might be able to address /dev -- it implies that /dev would become a pseudo-fs that could perhaps be mounted in a zone (with only the correct devices visible for the zone). This is usually called slash-dev-fs-- and it's already integrated into Nevada; zones was an important design consideration for the team who wrote it, and they did a nice job. slash-dev-fs uses UFS (or ZFS) as a backing store; I haven't thought about how that would interact with the NFS issue. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [install-discuss] DHCP Server in zone, WAS: Install software from SXCE DVD?
On Sat 17 Mar 2007 at 08:02PM, James Carlson wrote: Dan Price writes: - Currently must be tied to a physical NIC -- in other words you must dedicate a real NIC (not a logical interface) to each IP instance you want to run. This limitation is expected to be lifted when the Virtual NIC part of Crossbow is integrated. A physical DLPI Style 1 NIC -- Style 2 (such as hme and ce) won't work with it yet. (Clearview should fix this.) It might be nice to have a full list of the (otherwise Sun supported) NICs which don't work, if there isn't one already. I wasn't aware of this particular limitation. Do you know of such a list? Of interest to customers wishing to use this would likely be a list of some supported NICs whose drivers are DLPI style 1 (and especially those with 1 port). -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] QFS + zones
On Tue 06 Mar 2007 at 07:19PM, Rafa wrote: Hi, I have the following questions: Can be a zone configured in a QFS file system ? Probably, although the caveat is that the zone might not be upgradeable if you do an OS upgrade-- in that case, you would need to reinstall the zone. Can be mounted and shared, read and write, by serveral zones through Lofi ? I don't understand this question. Can *what* be mounted and shared, read and write, by serveral zones through Lofi? -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Capped memory observability
On Mon 05 Feb 2007 at 10:17PM, Mike Gerdts wrote: I just got a chance to start playing with the capped memory resource controls in build 56. At first blush, this looks to be *very* good stuff. My initial testing included some very basic single process memory hog tests and multiple process mmap(..., MAP_SHARED,...) tests. In each case, the limits kicked in as I expected, and prstat -Z running from the global zone gave what appeared to be accurate information. Great job! Thanks Mike, and thanks for taking the time to test this stuff. I also want to take this as a chance to publicly thank and congratulate Jerry and Steve, who dug in and did some incredibly hard work to make this project happen. I'll let Steve and Jerry answer your technical questions. For those who may be new to what Mike is talking about, check out some good information on this project, which revamps the zones/RM (resource management) integration: http://blogs.sun.com/jerrysblog/entry/containers_in_sx_build_56 http://opensolaris.org/jive/thread.jspa?messageID=74654 http://opensolaris.org/os/community/arc/caselog/2006/496/spec-txt/ http://opensolaris.org/os/community/arc/caselog/2006/598/spec-txt/ -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] configure tape drive under a zone ?
On Wed 31 Jan 2007 at 01:22PM, prakash wrote: HI, Any one came across.., Need to configure a tape drive under a zone, I have a machine with 4 zones, each zone will have seprate network and seprate tape drive to take backup how to achive this, if any one have idea please share with me !!! logical idea also good to analysis this ..., Prakash, This is what add device is for in zonecfg(1m). You can use this functionality to cause the zone to have the tape device included within it. Just name the tape drive by its path in /dev. Example: # zonecfg -z testzone zonecfg:testzone zonecfg:testzone add device zonecfg:testzone:device set match=/dev/rmt/0 zonecfg:testzone:device end zonecfg:testzone Then reboot the zone; you should then see /dev/rmt/0 available to apps running inside the zone. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [Fwd: Re: [zones-discuss] Re: zonemgr -s syntax]
On Wed 24 Jan 2007 at 01:04PM, The Real Warren Belfer wrote: John Clingan wrote: If we had used ksh, I am sure we would have gotten the bash question :) Developer preference I suppose. If you still have issues, blame Brad. He started it :) Hi, Well, shouldn't system utilities be written using tools available in all install metaclusters. Bash is only available in the End User install and larger, so folks using a Core install or smaller wouldn't be able to use this. OTOH, ksh is available in all clusters, Well zonemgr isn't part of the Solaris product, so no such rules apply (and there never were any such rules in the first place, although there probably should have been). As long as the zonemgr package states a package dependency on what it needs, then it can be considered an acceptably packaged utility, IMO. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Globle Zone information from Local Zone
On Thu 18 Jan 2007 at 01:11AM, prakash wrote: How to see Globle Zone information from Local Zone ? Which information? Any command to see the Globle zone name from local zone ? The zone name of the global zone is always global. Note that the host name and the zone name are not the same thing. If you want to see the hostname of the global zone from a non-global zone, you can't, really. Why do you need to do so? -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: RE: ?: named pipes between zones using shared filesystem
On Tue 12 Dec 2006 at 06:30PM, Steffen Weiberle wrote: Jerry Jelinek wrote On 12/12/06 16:54,: Steffen Weiberle wrote: Is it safe to generalize that non-LOFS file systems in Solaris 10 do not allow cross-zone interaction? procfs does not. namefs does not. tmpfs does not. sockfs does not. doors does not. What about all the others (I can't even name them all)? Steffen, One issue to be aware of with tmpfs is that a zone can consume all of your swap space. This is not a communication issue per se but is a cross-zone issue if the zone is compromised. We are solving this with the new zone.max-swap rctl described here: http://www.opensolaris.org/os/community/arc/caselog/2006/598/ This new rctl is part of the overall zones/rm improvement project we have been working on for a while now. Thanks, Jerry! I am waiting with open arms :) for this, and memory sets, and swap sets, and IP instances! Oh, and CPU caps. Wait, does this replace swap sets? Or is this a control to limit shared swap only? Maybe I can update that bullet item in my presentations!! So, in addition to security concerns, this customer was also asking about DoS prevention or minimization, and these will all contribute to that ability. Steffen, Probably you should review the duckhorn documentation (All of which has been forwarded to zones-discuss, and which are also available here: http://www.opensolaris.org/os/community/zones/zones_design_docs) and our Dec 4 KTD, the slides of which are at http://ktd.eng/. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: RE: ?: named pipes between zones using shared filesystem
On Tue 12 Dec 2006 at 03:58PM, Dan Price wrote: Steffen, Probably you should review the duckhorn documentation (All of which has been forwarded to zones-discuss, and which are also available here: http://www.opensolaris.org/os/community/zones/zones_design_docs) and our Dec 4 KTD, the slides of which are at http://ktd.eng/. Please excuse me-- this mail was intended to go only to Steffen. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ?: named pipes between zones using shared filesystem
On Mon 11 Dec 2006 at 04:14PM, Jeff Victor wrote: Mike, do you have a working code snippet that I can test? I have a 6/06 system, a Nevada build50 system, and can create others. I could write the code myself, but if you already have a tested sample... Isn't this not working because named pipes are implemented not as a filesystem builtin but using namefs? I would assume that you'd need to work out how to get the namefs mounts right. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone clone zfs best practices?
On Tue 28 Nov 2006 at 08:09PM, Peter Baer Galvin wrote: Hi, quick question on how best to use zone cloning with zfs. I've played with creating a master zone and then cloning it before its first boot. That seems to work fine. I'd rather create a master zone, boot it to walk through the smf initialization, and then clone it. I'm confused as to how this would work (or wouldn't) though. How will the networking in the clone be correct if the master has already gone through its sysid configuration? Or do you need to unconfig the clone and then sysid config it? Thanks for any best practice info around this issue. We automatically sys-unconfig the new zone at clone time-- but that doesn't affect the SMF manifest import. So: make your master zone, boot it, wait for manifest import to finish, then clone away, it should work just as you want. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
On Fri 03 Nov 2006 at 04:57PM, Erik Nordmark wrote: Dan Price wrote: 'list -i' religiously follows this idiosyncratic approach ;-) We have a plan to add 'zoneadm info' or some such to display all the runtime attributes of running zones. Hopefully we'll get to that in the next 12 months or so. I'd request that you hold off on adding list -l until we design 'info'. The problem is that we have requests from the users of IP Instances (folks that have used the bits on opensolaris.org) to have a way of displaying which datalink names are assigned to which running zones. If you start work on 'zonadm info' in 12 moths when would you expect to have it integrated? By get to it I mean have it finished -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
On Fri 03 Nov 2006 at 09:42AM, Erik Nordmark wrote: Thus if instead of using zonecfg to configure the boundary of the zone, things were spread across different commands (use dladm to assign link names to zones, use some zpool command to assign pools to zones, use zfs commands to assign zfs filesystems to zones), the I can see the point. This is not correct. Several major commands let you alter the boundary of the zone at runtime, by design. The difference between these commands and zonecfg is that only zonecfg lets you do that persistently. But given that zonecfg is used to specify the boundary of the zone (which link names, which pools, which file systems), it seems very unnatural that in order to look at what assignment was made one would have to use separate commands (be they dladm/pooladm/zfs). It seems natural to be able to look at that using a zone* command. You can priocntl a zone, you can mount things into it, you can ifconfig things into it, you can use poolbind to alter its pool binding, etc. This is by design. Note that zoneadm list is a bit idiosyncratic. It displays some things that are properties of the running state of the zone, which can not be found elsewhere (the zoneid and the state), but zoneadm list also displays a bunch of properties of the zones that are fixed (the uuid, brand, zonepath, etc) do not change as zoneadm manipulates the zone. 'list -i' religiously follows this idiosyncratic approach ;-) We have a plan to add 'zoneadm info' or some such to display all the runtime attributes of running zones. Hopefully we'll get to that in the next 12 months or so. I'd request that you hold off on adding list -l until we design 'info'. It's up to the network experts to decide whether dladm -z or some such should exist to provide zone scoping. The design principal is: If 'zone' is an important property of the object being managed, then it should be considered for display, since administrators may need to be aware of that information, or may need an easy way to get it. -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 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] PSARC/2006/598 Swap resource control; locked memory RM improvements
On Thu 26 Oct 2006 at 11:50AM, Steve Lawrence wrote: size of process image is pretty meaningless. If we can change pr_size to be swap reserved by process, then we could change SIZE to SWAP for all prstat(1m) output. Would such a change to psinfo_t be reasonable? You'd have to check in with Roger, I think (and doing so would probably be worth doing anyway). Adding a new field might be feasible. Currently a global or non-global zone can consume all swap resources available on the system, limiting the usefulness of zones as an application container. zone.max-swap provides a mechanism to I would rephrase that as the container of an application to avoid confusion with the Solaris feature set called Containers. I assume that the former was meant moreso than the latter even though Containers are Solaris' implementation of an application container. I'm not sure what you mean, but ok. By the Solaris feature set called Containers., do you mean zones + RM, or do you mean zones, xen, ldoms. Steve, I think the text is fine. This document isn't intended for consumption by customers, and the text is clear enough to anyone trying to absorb its meaning. Similarly, the ability to modify a zone's swap limit could be given to the zone's root user, which might be valuable in some situations. This would be analogous to the 'basic' privilege level. It would allow an advisory limit to be placed on a zone - a limit that the zone admin could modify in unusual circumstances. I just wanted to mention this idea so that it is not unintentionally overlooked. Currently, all zone.* rctls are not modifiable from a non global zone. The established mechanism for a zone admin to set rctls within the zone is via project.* rctls set on projects within the zone. Granted, in the zone.max-swap case, we are not proposing a project.max-swap, due to implementation complexity and risk. With sufficient customer damand, we could investigate implementing project.max-swap in the future. I think I'd agree that allowing a zone to modify its own zone.* rctls (perhaps only to lower them) is something we *could do* at some point. But I'm aware of neither an RFE for this nor stated customer demand. If someone wants this, then let's get that recorded as an RFE in the bug database, please. Thanks, -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Company offering Zones hosting
On Thu 05 Oct 2006 at 07:16PM, Alan Burlison wrote: Someone using Solaris 10 Zones for hosting provision, cool to see someone building a business around Zones. (No, I'm not affiliated with them in any way, neither have I used their services - just thought it was interesting ;-) http://www.mod3.co.uk/ Indeed. There are several. Do people think it would be right and proper to have a section of them on the OpenSolaris zones page? Or would that somehow seem like advertising? -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] [[today's email storm]]
Hi folks, Note that you're seeing a lot of email to zones-discuss today because we're shifting over (for non-members) from the queue-and-moderate model to the you must be a member model. Some mails from non-members have regrettably been in the queue a long time. At least some of those are now showing up. So please take note of the timestamps on the mails. The reason for the policy change is that I was the moderator, and I simply did not have the time to cope with the deluge of spams (about 400/month) that we get to the list. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones and network interfaces
On Fri 28 Jul 2006 at 03:18PM, Madhura Limaye wrote: Hello, I wanted to know if there can be a possibility of a non-global zone dying abruptly, similar to a system going down due to a panic? In short, no. If there is, can I expect that even in such a situation, any network interfaces configured for the non-global zone (whether through zonecfg or manually through ifconfig) will be removed? Or is there a possibility of the network interfaces for the non-global zone remaining as configured even though the non-global zone is down? down means something very specific for zones; see the comment for ZONE_IS_SHUTTING_DOWN through to ZONE_IS_FREE in usr/src/uts/common/os/zone.c. But I think by down you mean not running: If a zone is not running (i.e. it is in the installed state) then (unless there are bugs) there should be no network interfaces for it. [I've stripped the internal alias from the CC. Please don't crosspost between sun-internal and external lists] -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Some more Historical ARC cases published
[Note: As historical ARC cases get published, a notification is posted to arc-discuss (and in this case also zones-discuss.] As part of our team commitment to open development practices, the Zones team is busy publishing as much of our historical design documentation as is feasible. I am pleased to announce the availability of several new documents. Over the next month or so, we hope to complete the other 25 or so zones related cases which remain. Eventually, we'll get everything into our master index, at http://www.opensolaris.org/os/community/zones/zones_design_docs/ - PSARC 2003/687 - DTrace Updates for Zones http://www.opensolaris.org/os/community/arc/caselog/2003/687/ - PSARC 2003/690 - Zone Device Matching Update http://www.opensolaris.org/os/community/arc/caselog/2003/690/ - PSARC 2004/472 - GPEC for Zones http://www.opensolaris.org/os/community/arc/caselog/2004/472/ - PSARC 2004/532 - login(1) -z option http://www.opensolaris.org/os/community/arc/caselog/2004/532/ - PSARC 2004/620 - zlogin(1)/login(1) wtmpx behavior http://www.opensolaris.org/os/community/arc/caselog/2004/620/ - PSARC 2005/711 - Zone move and clone http://www.opensolaris.org/os/community/arc/caselog/2005/711/ - PSARC 2006/030 - Zone Migration http://www.opensolaris.org/os/community/arc/caselog/2006/030/ - PSARC 2006/153 - Zones ZFS Integration http://www.opensolaris.org/os/community/arc/caselog/2006/153/ - PSARC 2006/163 - SMF_ZONENAME http://www.opensolaris.org/os/community/arc/caselog/2006/163/ - PSARC 2006/269 - Zone Boot Arguments II http://www.opensolaris.org/os/community/arc/caselog/2006/269/ - PSARC 2006/307 - zone migration dry-run http://www.opensolaris.org/os/community/arc/caselog/2006/307/ -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Proposal: Zone Boot Arguments II
On Sat 22 Jul 2006 at 02:06PM, Manish Agrawal wrote: Is there a timeframe when it will be possible to specify boot parameters in the zone configuration. I plan to use zones in a classroom environment and would like to script the process of destroying existing zones and recreating them at the end of every semester. The ability to specify boot parameters in the zone configuration would be a great help so I don't have to go through the initial boot sequence for each zone every semester. I'm not sure why boot arguments solves your problem (see Matty's response)-- you may be looking for sysidcfg support which is already present, or clone, which would help you snap off many identical zones. Anyway, as for boot arguments, I checked in support for this feature into build 44 of Solaris Nevada. The following are supported: -s (single user) -m smf_options -i /path/to/init All Solaris Express builds starting with B44 should have support for setting the 'bootargs' property in the zonecfg: zonecfg:myzone set bootargs=-s Boot arguments may eventually appear in an update for Solaris 10 but I couldn't reasonably speculate as to which one (except not the next one; that one is already filled up with features). Thanks, -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] monitoring local zone crash with global kthread?
On Fri 30 Jun 2006 at 02:53PM, Glen Kriekenbeck wrote: I'm working with an ISV who asks: We have a kernel module which we need to modify to support non-global zones. [This kernel module implements a file system,] and on normal shutdowns the unmount will let us know this Zone is no longer using the file system. However, for unexpected shutdowns (crashes) we were thinking of creating a kernel thread and registering it be notified when a Zone terminates (I read about this someplace). What is the interface for doing this? Would I create 1 kernel thread on the whole machine and have it notify us of any Zone going away, or do we need to register with each Zone? Thanks for any pointers to any information (and/or appropriate sources)! There's no such thing as a zone crash-- so there is really no need to do this. As long as the filesystem is unmountable in the usual way (i.e. via umount(2)) then the filesystem should work OK as far as I can recall. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
