Re: [zones-discuss] Annoying zone boot failure
this should never happen. please file a bug. are you seeing this on s11 or s10? could you also provide more deails about how you hit this problem and what you did to fix it? (if you could provide a way to reproduce this problem that'd be great.) ed On Tue, Nov 20, 2012 at 12:00:19PM +1300, Ian Collins wrote: > On 11/19/12 14:19, Ian Collins wrote: > >After a recent system panic, the zones service failed to start due to > >the first zone failing to boot. The boot fails with > > > >ERROR: could not open master side of zone console for wiki to acquire > >slave handle: Device busy > > > >I tried detaching and reattaching the zone but this didn't change anything. > > > >Can this be fixed by removing the /dev/zcons/wiki symlinks or the > >underlying pseudo devices? > > > >When are the pseudo devices created? > > When the zone boots. > > It turns out there are two zones attempting to use the same console devices: > > s -l /dev/zcons/sword/ > total 0 > lrwxrwxrwx 1 root root 0 Nov 11 10:46 masterconsole > -> ../../../devices/pseudo/zconsnex@1/zcons@1:masterconsole > lrwxrwxrwx 1 root root 0 Nov 11 10:46 zoneconsole -> > ../../../devices/pseudo/zconsnex@1/zcons@1:zoneconsole > > ls -l /dev/zcons/wiki > total 0 > lrwxrwxrwx 1 root root 0 Nov 20 11:47 masterconsole > -> ../../../devices/pseudo/zconsnex@1/zcons@1:masterconsole > lrwxrwxrwx 1 root root 0 Nov 20 11:47 zoneconsole -> > ../../../devices/pseudo/zconsnex@1/zcons@1:zoneconsole > > Which explains why the devices are busy! > > Even after detaching, deleting, recreating and attaching, the zone > still attempts to use the same devices. > > In the end I resorted to detaching, deleting, recreating with a new > name and attaching. > > PITA. > > -- > Ian. > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Bridging at Zones.
oops. please ignore my advice and follow erics. (although, even if you do that i'm not if you'll be able to create a bridge inside a zone.) ed On Wed, Aug 22, 2012 at 11:19:35AM -0300, Daniel Requena wrote: > Hi Edward, > >I believe i was not so clear about the problem. >I'm not trying to create vnics from inside the zone... I'm trying to run > this command inside the container: "dladm create-bridge -P trill -l net0 > mytrillBridge" (net0 being the vnic create from global zone). >Like I said, Trilld have a requisite that in order to run, a bridge in > Trill protect mode must be initiated, but the command above output that I > cannot create a bridge since net0 is a vnic. >Eric suggest: "You may need to delegate physical NICs to the > container..." and I believe that virtualizing Solaris from a Vmware ou Xen > Hypervisor, giving a lot of "vmware network cards" should be enough... > If you or anybody else on the list have another idea of how to run > trilld from inside a Container I would love to know. > Thank you for your interest and time. > > Regards. > > Daniel. > > > 2012/8/21 Edward Pilatowicz > > > you can't create vnics from inside a zone. (it's not supported.) > > > > but the global zone can create additional vnics and give them to the > > zone. the easiest way to do this is to have the global zone > > administrator update the zonecfg for you zone to include multiple "anet" > > resources, one for each vnic that you want. when they create an "anet" > > resource they can specify the physical link that the vnic should be > > created on top of (via the anet lower-link property). > > > > ed > > > > On Tue, Aug 21, 2012 at 02:58:04PM -0300, Daniel Requena wrote: > > > Hello, > > > > > >I'm trying to run a simulation for my master thesis using Solaris > > > Containers, but I'm having a problem. > > >I need to run Trilld inside the containers, but in order to run > > trilld I > > > must be able to Bridge network cards... when I try to run dladm to create > > > the bridge inside a container, it says that a vnic cannot be bridged... > > :/ > > >The main objective in this simulation is to emulate a trill switch > > cloud > > > all interconnected but this "bridge" problem is killing me.. > > >Is there a way to use a different nic inside the containers so I can > > run > > > trilld? > > >Any help or idea is appreciated. > > > > > > Regards. > > > Daniel. > > > > > ___ > > > zones-discuss mailing list > > > zones-discuss@opensolaris.org > > > > > > > -- > Atenciosamente > Daniel Requena ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Bridging at Zones.
you can't create vnics from inside a zone. (it's not supported.) but the global zone can create additional vnics and give them to the zone. the easiest way to do this is to have the global zone administrator update the zonecfg for you zone to include multiple "anet" resources, one for each vnic that you want. when they create an "anet" resource they can specify the physical link that the vnic should be created on top of (via the anet lower-link property). ed On Tue, Aug 21, 2012 at 02:58:04PM -0300, Daniel Requena wrote: > Hello, > >I'm trying to run a simulation for my master thesis using Solaris > Containers, but I'm having a problem. >I need to run Trilld inside the containers, but in order to run trilld I > must be able to Bridge network cards... when I try to run dladm to create > the bridge inside a container, it says that a vnic cannot be bridged... :/ >The main objective in this simulation is to emulate a trill switch cloud > all interconnected but this "bridge" problem is killing me.. >Is there a way to use a different nic inside the containers so I can run > trilld? >Any help or idea is appreciated. > > Regards. > Daniel. > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how to unset a publisher in a zone?
On Mon, Feb 20, 2012 at 02:56:23AM -0800, Ian Collins wrote: > On 02/20/12 10:06 PM, gerard henry wrote: > >hello all, > >after upgrading from S11X to S11, i'm unable to attach a zone due > >to a missing publisher. I'm trying to remove the old publisher but > >i have this: > > > >root@electre:~# pkg -R /zones/test_bd/root/ publisher > >PUBLISHER TYPE STATUS URI > >solaris (syspub) origin online file:///mnt/repo/ > >solaris (syspub) origin online > >proxy://http://localhost:1/ > >latp origin online > >http://electre:1/ > >root@electre:~# pkg -R /zones/test_bd/root/ unset-publisher solaris > > > >pkg unset-publisher: Removal failed for 'solaris': solaris is a > >system publisher and cannot be unset. > > > >there are 2 publishers with the same name, how can i correct this problem? > > to use the proper terminology, you have one publisher with two origins. > I had the same problem a while back and I think I used set-publisher > with -g to add the correct publisher and -G to remove the bad one. > correct, you cannot run unset-publisher for any publisher configured with the "syspub" attribute. to clean up origins for such a publisher you could run: pkg set-publisher -G '*' solaris > It wont let you remove the one with the queer URI (where doe that > come from I wonder?), but it doesn't appear to do any harm. > assuming that the queer uri is the "proxy://" one, that one is automatically added into zones via the system-repository service. basically, every publisher and origin accessible in the gz is accessible to a ngz via these type special proxy origins. this ensures that ngz can install software that is in compatible with the gz. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Not Starting Properly?
On Tue, Dec 13, 2011 at 09:44:23AM -0600, Derek McEachern wrote: > Thought I would just send an update on this. Thanks for the all the > suggestions. > > To get around our particular issue I just added some retry logic to the > /etc/init.d/ script. When it runs it if finds that the operation has failed > it pauses for a second and will try again. It will try up to three times > before giving up. > it'd be interesting to know what particular operation is failing within the script... ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Expanding the set of packages installed into a Zone?
On Fri, Nov 11, 2011 at 08:41:44AM +1300, Ian Collins wrote: > On 11/11/11 08:01 AM, Ian Collins wrote: > >On 11/11/11 02:39 AM, Mike Gerdts wrote: > >>On Thu 10 Nov 2011 at 08:32PM, Ian Collins wrote: > >>>On 10/10/11 07:20 PM, Edward Pilatowicz wrote: > >>>>by default packages that get installed into a zone are specified in the > >>>>default AI manifest used to install zones. you can find that manifest > >>>>here: > >>>> > >>>> /usr/share/auto_install/manifest/zone_default.xml > >>>I can't see that file (or the auto_instal directory) on any of my > >>>systems. Has it moved? > >>That file exists in Solaris 11 as part of the auto-install-common > >>package: > >> > >>$ pkg search /usr/share/auto_install/manifest/zone_default.xml > >>INDEX ACTION VALUEPACKAGE > >>path file usr/share/auto_install/manifest/zone_default.xml > >>pkg:/system/install/auto-install/auto-install-common@0.5.11-0.175.0.0.0.2.1482 > >> > >>With Solaris 11 Express, the list of packages was hard coded into > >>scripts under /usr/lib/brand/ipkg. What are you running? > >> > >Solaris 11 Express with the latest updates from the support repo. > > > >I'm getting an odd problem creating zones and I wanted to check the > >package list: > > > >Package State Update Phase 45/45 > >Image State Update Phase 2/2 > >Installing: Additional Packages (output follows) > >Creating Planpkg: 'SUNWbip' matches multiple packages > > SUNWbip > > compatibility/packages/SUNWbip > > > >ERROR: failed to install package > > > I removed SUNWbip from /usr/lib/brand/ipkg/pkgcreatezone and the > zone installed OK. I'll add the package in the zone later. > > Someone should have a look at a proper fix! > this was a known bug: 17806 cannot create local zone on snv_156 after 158 was added to repository https://defect.opensolaris.org/bz/show_bug.cgi?id=17806 it was fixed in snv_156. the problem only happens if your using s11 express and you have a repo with S11 in it. a fix for this issue has not been back published to s11 express. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Old publishers stopping zoneadm attach -u in Solaris 11?
you should safely be able to delete that publisher from the zones. (in s11, zones inherit publishers from the global zone so they don't actually need any local publisher configuration.) ed On Thu, Nov 10, 2011 at 02:13:24PM +1300, Ian Collins wrote: > I'm trying to reattach my zones on a newly upgraded Solaris 11 > system. They have all been through the dsconvert phase and are > currently detached. > > zoneadm attach -u is failing with to references to stale publishers > (from a log): > > * > [Thursday, November 10, 2011 02:09:18 PM NZDT] Pinning datasets > under rpool/zoneRoot/tait_ldap1 > > [Thursday, November 10, 2011 02:09:18 PM NZDT] Converting detached > zone boot environment 'zbe-6'. > [Thursday, November 10, 2011 02:09:18 PM NZDT] Unmounting > /zoneRoot/tait_ldap1/root > [Thursday, November 10, 2011 02:09:19 PM NZDT] setting ZFS > property zoned=on on rpool/zoneRoot/tait_ldap1/rpool > [Thursday, November 10, 2011 02:09:19 PM NZDT] setting ZFS > property canmount=noauto on rpool/zoneRoot/tait_ldap1/rpool/ROOT > [Thursday, November 10, 2011 02:09:20 PM NZDT] setting ZFS > property mountpoint=legacy on rpool/zoneRoot/tait_ldap1/rpool/ROOT > [Thursday, November 10, 2011 02:09:21 PM NZDT] Mounting boot > environment in rpool/zoneRoot/tait_ldap1/rpool/ROOT/zbe-6 at > /zoneRoot/tait_ld > ap1/root (including child datasets) > [Thursday, November 10, 2011 02:09:21 PM NZDT] Preparing to mount > rpool/zoneRoot/tait_ldap1/rpool/ROOT/zbe-6 at > /zoneRoot/tait_ldap1/root > [Thursday, November 10, 2011 02:09:21 PM NZDT] Mounting > rpool/zoneRoot/tait_ldap1/rpool/ROOT/zbe-6 at > /zoneRoot/tait_ldap1/root/ with ZFS t > emporary mount > [Thursday, November 10, 2011 02:09:21 PM NZDT] Attaching... > [Thursday, November 10, 2011 02:09:21 PM NZDT] existing > [Thursday, November 10, 2011 02:09:21 PM NZDT] Installing: Using > existing zone boot environment > [Thursday, November 10, 2011 02:09:21 PM NZDT] Mounting boot > environment in rpool/zoneRoot/tait_ldap1/rpool/ROOT/zbe-6 at > /zoneRoot/tait_ld > ap1/root (including child datasets) > [Thursday, November 10, 2011 02:09:21 PM NZDT] Preparing to mount > rpool/zoneRoot/tait_ldap1/rpool/ROOT/zbe-6 at > /zoneRoot/tait_ldap1/root > [Thursday, November 10, 2011 02:09:21 PM NZDT] Sanity Check: > Passed. Looks like a Solaris system. > [Thursday, November 10, 2011 02:09:21 PM NZDT] Zone BE root > dataset: rpool/zoneRoot/tait_ldap1/rpool/ROOT/zbe-6 > [Thursday, November 10, 2011 02:09:22 PM NZDT] > Cache: Using /var/pkg/publisher. > [Thursday, November 10, 2011 02:09:22 PM NZDT] Updating image format > pkg: 2/4 catalogs successfully updated: > > Unable to contact valid package repository: > http://pkg.opensolaris.org/contrib > Encountered the following error(s): > Unable to parse repository response > > Invalid pkg(5) response from http://pkg.opensolaris.org/release: > Attempting operation 'versions' version 0: > VaueError while parsing response > > [Thursday, November 10, 2011 02:09:43 PM NZDT] ERROR: Updating image > format failed > *** > > Is the failure due to the dead repository? > > I have removed all reference to them in the global zone: > # pkg publisher > PUBLISHER TYPE STATUS URI > solaris origin online > http://pkg.oracle.com/solaris/release/ > > -- > Ian. > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Expanding the set of packages installed into a Zone?
On Fri, Oct 07, 2011 at 12:23:30PM -0700, Michael Speer wrote: > All, > > I have two questions based on what I have been seeing where I don't see > packages of interest being > installed into a zone I create when the package exists in the global zone. > > 1) Where is the list of packages kept that will be installed into new zone? > How does this list get modified? > by default packages that get installed into a zone are specified in the default AI manifest used to install zones. you can find that manifest here: /usr/share/auto_install/manifest/zone_default.xml looking inside you can see that the default package that we install (which determines which other packages get installed) is: group/system/solaris-small-server you can also create your own AI manifest which specifies which packages you'd like to have installed in the zone. > 2) How do I use the pkg utility to install a package to an alternative root > path? > pkg -R install but for zones it's better to boot them, zlogin, and then run pkg. > 3) Do I need to create a new entire incorporation to overcome this issue? > no. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Has the restriction on sharing from a zone been removed yet?
because s10 is (or was) our primary development release and we don't backport every feature to s10/s9/s8/etc. ed On Thu, Sep 29, 2011 at 08:53:34AM -0400, hung-sheng tsao wrote: > Why only in s11? > > On 9/28/11, Ian Collins wrote: > > On 09/29/11 09:50 AM, Edward Pilatowicz wrote: > >> nfs server is now supported in a zone on s11. > >> smb server is not. > > > > OK, thanks Ed. > > > > I thought the original ARC case for PRIV_SYS_SHARE would have enabled both? > > > > -- > > Ian. > > > > ___ > > zones-discuss mailing list > > zones-discuss@opensolaris.org > > > > -- > Sent from my mobile device > > Hung-Sheng Tsao, Ph.D. > laot...@gmail.com > http://laotsao.wordpress.com > cell:9734950840 > gvoice:8623970640 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Has the restriction on sharing from a zone been removed yet?
On Thu, Sep 29, 2011 at 04:57:12PM +1300, Ian Collins wrote: > On 09/29/11 09:50 AM, Edward Pilatowicz wrote: > >nfs server is now supported in a zone on s11. > >smb server is not. > > OK, thanks Ed. > > I thought the original ARC case for PRIV_SYS_SHARE would have enabled both? > it's not just a matter of enabling privs. there was a lot of work that when into enabling nfs that would also have to be done for smb. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Has the restriction on sharing from a zone been removed yet?
nfs server is now supported in a zone on s11. smb server is not. ed On Tue, Sep 27, 2011 at 06:19:34PM +1300, Ian Collins wrote: > Has the restriction on sharing ZFS filesystems vis nfs or smb from > a zone been removed in the Solaris 11 branch yet? > > If not, will it be? > > Thanks. > > -- > Ian. > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Add mountpoint to zone without a reboot
On Wed, Aug 25, 2010 at 11:32:48AM -0700, Mike DeMarco wrote: > Is it possible to add a new zfs filesystem to a zone without rebooting the > zone? > > I have a need to add a filesystem to a zone for a couple of weeks but can not > take an outage of the zone. you can add zfs filesystem by temporarily mounting them in a running zone either directly or by using lofs. using lofs: mount -F lofs /export/foo /zonepath/root/foo using zfs: zfs set mountpoint=/zonepath/root/foo rpool/export/foo you can't add them via the zonecfg(1m) "dataset" or "fs" resources without a reboot. note that if you want the zone to be able to manage the zfs filesystem (ie, create new filesystems, set properties, etc) then you have to add it via the "dataset" resourse, which will require a reboot. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Q: how can I set up an Exclusive-IP zone for an ftp/rlogin/telnet server?
On Mon, Aug 09, 2010 at 11:07:39AM -0700, eiji@oracle.com wrote: > Hi, > > This might be a naive question, but I'm wondering how I can set up > an Exclusive-IP zone for an ftp/telnet/rlogin/rsh server? > > I can access the global zone from the exclusive zone w/ ftp/telnet/rlogin/rsh, > but I cannot in the other way like: > > [global zone][exclusive-IP zone] > > ftp/rlogin/telnet/rsh=> NG > OK <= ftp/rlogin/telnet/rsh > > (example) > >// exclusive-IP => global > > r...@wave189-zone:~# ftp 18.0.100.2 > Connected to 18.0.100.2. > 220 wave189.West.Sun.COM FTP server ready. > Name (18.0.100.2:root): > >// global => exclusive-IP > > r...@wave189: ~ # ftp 18.0.100.4 > ftp: connect: Connection refused > > svcs doesn't show any info about them on the exclusive-IP zone. > > (global) > > r...@wave189: ~ # svcs ftp > STATE STIMEFMRI > online 10:07:25 svc:/network/ftp:default > > (exclusive-IP) > > r...@wave189-zone:~# svcs ftp > svcs: Pattern 'ftp' doesn't match any instances > STATE STIMEFMRI > sure, zones can do this. but it looks like you don't have the ftp server software installed in the zone. try installing it: pkg install service/network/ftp i think the same applies to telnet/rlogin/rsh. those services are not installed by default. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] looking for install without repo options
On Tue, Jul 27, 2010 at 02:17:45PM -0700, Sunay Tripathi wrote:
> On 07/27/10 01:06 PM, Edward Pilatowicz wrote:
> >On Mon, Jul 26, 2010 at 10:54:24PM -0700, Sunay Tripathi wrote:
> >>Guys,
> >>
> >>I think we had discussed allowing a ipkg brand zone to be installed
> >>without a network i.e. going to a repo if I already have a installed
> >
> >offline zone install is not available today. there is a bug for this
> >and we will have it someday:
> >
> >1947 Offline zone creation is impossible
> >https://defect.opensolaris.org/bz/show_bug.cgi?id=1947
>
> Ah. Although it seems like its labeled an RFE but this is a
> regression from earlier native zones where one could create
> zone on his laptop while sitting on a beach. Now I am just
> a developer but for most large data center managers, each
> machine needing to go to a repo to create a zone is going
> to put them in a very bad mood ;^) I would suggest upping
> the priority on that ...
>
hm. if i was a data center manager (or developer) sitting on a beach, i
don't think i'd be thinking about zone installs. i'd probably also be
in a pretty good mood, assuming the weather was nice. but yes, this is
arguably a regression from s10 zone install.
> >>system running. Can someone tell the correct options? I am trying
> >>the -d option but that fails ...
> >># zoneadm -z test install -d /
> >>pkg list: no packages matching 'entire' installed
> >>you must specify -u (sys-unconfig) or -p (preserve identity).
> >>brand-specific usage:
> >> install {-a archive|-d path} {-p|-u} [-s|-v]
> >>
> >
> >since you don't have entire installed it's not possible to install valid
> >zones (even if you have an accessible repo). there is a bug on this:
> >
> >16568 zoneadm install can create out of sync zones if entire has been removed
> >https://defect.opensolaris.org/bz/show_bug.cgi?id=1947
>
> OK. If you address this at least, its a good start.
>
> >i'd recommend that you install zones before running onu.
>
> The attach -u after onu still fails although I haven't tried
> to debug that.
attach -u should succeed as of snv_132. (with the fix for 12738.) of
course you still need to have access to the repo that onu used when
updating your gz.
> >
> >i'd also strongly recommend running recent builds. if your running
> >older builds then lots of stuff will be broken.
>
> Thats what got me here in the first place :)
>
well, in another email you mentioned you were using external repos. so
even if you've onu'd to more recent bits, you don't have the most recent
ips consolidation bits, which is where the fix for 12738 is. i don't
remember what the most recently available external build is, but if you
started with something older than snv_132 then you might want to
consider building and installing more recent ips bits (in addition to ON
bits) if you want to use zones.
ed
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] looking for install without repo options
On Mon, Jul 26, 2010 at 10:54:24PM -0700, Sunay Tripathi wrote:
> Guys,
>
> I think we had discussed allowing a ipkg brand zone to be installed
> without a network i.e. going to a repo if I already have a installed
offline zone install is not available today. there is a bug for this
and we will have it someday:
1947 Offline zone creation is impossible
https://defect.opensolaris.org/bz/show_bug.cgi?id=1947
> system running. Can someone tell the correct options? I am trying
> the -d option but that fails ...
> # zoneadm -z test install -d /
> pkg list: no packages matching 'entire' installed
> you must specify -u (sys-unconfig) or -p (preserve identity).
> brand-specific usage:
> install {-a archive|-d path} {-p|-u} [-s|-v]
>
since you don't have entire installed it's not possible to install valid
zones (even if you have an accessible repo). there is a bug on this:
16568 zoneadm install can create out of sync zones if entire has been removed
https://defect.opensolaris.org/bz/show_bug.cgi?id=1947
i'd recommend that you install zones before running onu.
i'd also strongly recommend running recent builds. if your running
older builds then lots of stuff will be broken.
ed
___
zones-discuss mailing list
zones-discuss@opensolaris.org
[zones-discuss] how dynamic is your zones network configuration?
hey all, i had a quick questions for all the zones users out there. after you've configured and installed a zone with ip-type=shared (the default), how often do you change the network interfaces assigned to that zone via zonecfg(1m)? frequently? infrequently? never? only when moving from testing to production? etc... thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [pkg-discuss] linked image content policy proposal
On Fri, May 28, 2010 at 05:04:07PM -0700, Danek Duvall wrote:
> "core-os" seems like it might end up being overly broad, given that, at
> least at the moment, it covers the entire WOS.
>
actually, that is kinda the point (ie, covering the entire WOS).
one of the features of sparse zones in s10 that system administrators
like is that they can basically manage all their "system software" (ie,
the WOS, or as they usually call it "all+oem") from the global zone, but
each zone can still have an independent application stacks that can be
managed from within the zones. so by providing {sync|mirror}:core-os,
we can basically allow for maintenance of all the "system software" from
the global zone while zones are still able to install and run whatever
additional application they want. (and in the case of "sync", the zone
can still be minimized.)
if administrators want to allow different WOS bits between the zone and
global zone then they should use minimal and not core-os.
> How is "minimal" defined? Is it hardcoded to a list of packages somewhere?
>
the minimal set of packages is all packages that are tagged with the
"cip" attribute. the "cip" attribute is a new packaging attribute that
we'll be introducing, and it will indicate that a package must be kept
in sync between a zone and the global zone. basically these will be
packages that define or consume kernel interfaces. it'd be impossible
to hard code this set of packages into a list because we don't know
about all the publishers that may publish packages with this attribute.
(more about this below.)
> It seems to me that you might as well make the leap to allowing package
> names (or patterns) for the group, and replace "minimal" with some
> well-known package name that defines the minimal set of packages, and
> "core-os" with the incorporations that carry those attributes. Or maybe
> not ... ?
>
the argument against this is that i can't represent the minimal set of
packages as another package without making that a dynamic package. for
example, the virtualbox package will have the "cip" attribute set since
it delivers a kernel module and an application that consumes those
kernel interfaces. so if we had a package that represented all cip
packages, the contents of that package would vary based on if an image
was configured with the "extra" repo or not. also, we don't know what
third parties might deliver packages that need to have the "cip"
attribute set.
> "sync" and "mirror" act very much like "incorporate" and "require" do for
> dependencies (though the versioning for the depend actions isn't exact). I
> wonder if there's some convergence, either in terminology or in mechanism,
> that could be done here. I'm not sure that sync and mirror really say what
> you want them to, but perhaps I've been drinking the pkg(5) terminology
> kool-aid for too long.
>
they are similar and in fact internally the implementation uses
"incorporate" and "require" dependencies to implement these policies.
i could adopt the same terminology if that seemed more intuitive to
folks, but at the same time i'll point out that the behavior of
sync/mirror vs incorporate/require is not exactly the same. (and i
don't really think it'd be appropriate, but i could always be
convinced.)
specifically, both the sync/mirror policies have the rule that you can't
install a package governed by the policy into a zone unless it's
already installed in the global zone. so for example, say you had a
policy of "require:core-os" (instead of "mirror:core-os"). given the
existing package terminology, to me this seems to imply that you should
have all core-os packages installed. but that's not actually the case.
the only core-os packages installed in a zone would be those that are
installed in the global zone, and a zone would also be unable to install
new core-os packages. (installing new core-os packages would have to be
done in the global zone, and the process of doing that would
automatically install those packages into the non-global zone as well.)
> Will administrators in the zone be able to modify these policies?
> Typically "image properties" are stored in the image, and not external to
> the image, which means that zone admins could violate policy set by gz
> admins.
>
no. so the storage of linked image properties varies by different
linked image type. this bleeds over into the larger linked image
design. in the case of zones linked images, the linked image content
policy will probably be set via zonecfg(1m) in the global zone.
subsequently the policy will be conveyed to the zone and the pkg(1m)
command within that zone will respect the policy that has been given to
it.
obviously a user in a zone could hack around this and violate the
policy, but then again they have write access to their filesystems and
in the end they can do whatever they want. (incidentally, this is why we
never trust a zone image once it's been booted.)
ed
___
[zones-discuss] linked image content policy proposal
[ cross-posted to pkg-discuss and zones-discuss. sorry for any dups. ] hey all, one issue that linked images has to deal with is how specify the content relationship between images. i've written up the proposal below describing one way this could be done. any comments or feedback would be greatly appreciated. thanks ed " please ensure that the vim modeline option is not disabled vim:textwidth=72 -- Linked image content policies - v0.1 The contents of a linked image will be controlled by a linked image property called "li-content-policy". This content policy value will take the form of: [:] The value determines the set of packages that the policy gets applied to. In the future we could allow users to define their own package groups that a content policy could be applied to, but initially the following three package groups are proposed: - minimal - the minimal set of packages that need to be kept in sync between a global zone and non-global zones. - core-os - all packages that are incorporated by a package which has a pkg.depend.install-hold value of core-os*. - all - all available packages. The actual value determines the policy behavior applied to the specified set of packages. Initially the following policies are proposed: - mirror - Requires that a package installed in a parent image must also be installed in the child image at the same version and timestamp. - sync - Requires that a package be installed in a parent image before it can optionally be installed in a child image at that same version and timestamp. Both the policies above require that a package group be specified, but in the future there may be other policies that do not require the specification of a package group. Here are some examples of how these different policies and pkg groups can be combined and used in the context of zones. - sync:minimal - If this setting was applied to a zone then it would keep the minimal amount of packages in sync between a zone and the global zone. Any packages in the minimal set would need to be installed in the global zone before they could be install in a zone. Also, any package in the minimal set that are installed in a zone must have exactly the same version and timestamp as the packages in the global zone. Packages outside the minimal set can be at any version as long as all their dependencies can be satisfied. This will be the default content policy for zones. - sync:core-os - If this setting was applied to a zone then the set of core-os packages installed in that zone would be equivalent to, or a subset of, the set of core-os packages installed in the global zone. The zone could still be minimized, and it would still be free to install and manage any software as long as it wasn't tagged as core-os. All core-os packages would need to be managed and updated from the global zone. - sync:all - If this setting was applied to a zone then the set of packages installed in that zone would be equivalent to, or a subset of, the set of packages installed in the global zone. The zone could still be minimized, but it would be unable to install any software not already installed in the global zone. All software would need to be managed and updated from the global zone. This will be the default content policy for scratch zone root images. [1] - mirror:minimal - This setting would be allowable, but wouldn't be hugely useful. - mirror:core-os - If this setting was applied to a zone then the set of core-os packages installed in that zone would be equal to the set of core-os packages installed in the global zone. The zone could not be minimized, but it would still be free to install and manage any software as long as it wasn't tagged as core-os. All core-os packages would need to be managed and updated from the global zone. - mirror:all - If this setting was applied to a zone then the set of packages installed in that zone would be equal to the set of packages installed in the global zone. The zone could not be minimized and it would not be able to install any software not already installed in the global zone. All software would need to be managed and updated from the global zone. In the future it may be desirable to support other content policies. Some (not fully thought through) examples of possible future policies could be: - partial - If this setting was applied to a child image then any package installed in the parent image would be able to satisfy any package dependency requirements on that package for packages installed in the child image. Also, any packages installed in both the child and parent images would need to be at the exact same version and timestamp. These packages could also be safely removed from the child image at any time. Footnotes: [1] - Scratch zones are temporary zones that are never bo
Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?
more information is needed about your architecture and what your trying to do. first off, as has been pointed out, if your not in user context getzoneid() isn't really that useful. second, below you keep mentioning "at boot time". are you talking about system boot time? or zone boot time? at system boot time, there are never any zones on the system and the kernel has no knowledge about any future zones. adding an SMF service to tell IB about zones at this point doesn't make any sense since that information could always change when someone runs zonecfg(1m). so your device should be able to attach and initialize itself without any knowledge of what zone is going to be using it. the first time the kernel learns about a zone is when that zone is brought into the ready state. this is also the point at which a zoneid is actually allocated for a zone. once this is done, device and resource allocation can happen for the zone. so if there's special setup that need to be done to associate IB devices with zones, this is the point at which it should happen. userland can tell the kernel which IB devices should be bound to a zone, and those devices can do whatever re-configuration is necessary. ed On Thu, May 27, 2010 at 10:31:27PM -0700, eiji@oracle.com wrote: > Hi, > > I'm wondering if there is a way to get a zoneid from kernel even though > it's not in user context. If it's possible, this is useful for us to > activate an HCA port in the exclusive-IP zone at boot time. > > Here's the background info. > > Currently the IP path info is gotten when the driver is attached, then > an HCA port can be ready for RDSv3, but this way is for the global zone, > and it doesn't work well for the exclusive-IP zone because the driver cannot > get the zoneid when it's attached (so far). After all, we have to wait until > customers run a command for RDSv3 in the zone, but the port should be ready > at boot time w/o any customers' actions. It'd be better off getting it > in the driver attach, but I don't know if it's possible. > > If it's not possible to get a zoneid from kernel if it's not in user context, > then is there any recommended method to get it at boot time? I'm thinking > maybe by using SMF, we can invoke an appropriate command (like ifconfig) at > boot time to activate HCAs in the exclusive-IP zones, but if there is a proper > way for this kind of purpose, that'd be better. > > Thanks, > > -Eiji > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] new zones community leaders
hey all, i wanted to propose zone community leadership status for the following folks: Frank Batschulat Gary Pennington John Levon Susan Kamm-Worrell ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How can I get a gnome desktop running in a zone?
On Fri, Apr 02, 2010 at 04:24:58AM -0700, tomwaters wrote: > Hi guys, I have set up a zone, (zone1), and when I log in all I get is the > command prompt. > > How can I get a desktop inside this zone? Pls. provide simple steps or a link > to a guide. > > I'd be happy to vnc in to it if required. > > I have googles and read, but I can not find a solution. i'd recommend using vnc or setting up an xdmcp server. sorry, but i don't have pointers to any guides. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Upgrading Opensolaris system with zones
On Tue, Mar 23, 2010 at 01:58:13PM -0400, Nandini Mocherla wrote: > Can anyone point me to the documentation on upgrading Opensolaris > system with non-global zones? I have a system running b130 > (previously upgraded once) with 4 non-global zones, 3 zones running > b129 and 1 zone running b130. > > I need to update the global zone to the latest build and also update > all the non-global zones. Before I upgrade the global zone to the > latest build is it necessary to update all the 3 zones to b130? If > so how? Thanks, > from: http://opensolaris.org/jive/thread.jspa?threadID=123301&tstart=1 ---8<--- [1] pkg image-update (with zones attached) [2] after reboot to the new BE detach the zones [3] zoneadm attach -u zones ---8<--- ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] recovery from removal of "entire"
On Tue, Mar 23, 2010 at 10:16:58AM -0400, John D Groenveld wrote: > I have a build 129 installation with a few zones that > will not attach because I removed "entire" from global. > Yes, I know "entire" is required. > > I can upgrade to 134, but I'm not sure how that will > work if my zones are detached. > don't detach your zones before doing the upgrade. if you do, they will not be snapshotted and cloned. > I don't care if I can't downgrade back to 129, but I do > need to get global and the zones running and up to 134. > > Suggestions? > normally, you would do an image-update in the gz, then reboot to the new image, detach your zones, and attach -u them. but this procedure currently doesn't work if you don't have entire installed. this is a known bug that is being worked on: 14684 zone attach incorporation logic needs enhancement http://defect.opensolaris.org/bz/show_bug.cgi?id=14684 hence, before doing your image update, i'd recommend re-installing entire. (either before doing the image-update or after doing it, either should be ok.) after you're done detaching and attaching -u all your zones, feel free to uninstall entire again. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] svcadm not executing methods
On Tue, Mar 23, 2010 at 11:42:10AM -0700, Allan wrote: > Hello, > > This time I decided to create a zone from scratch and see if the problem > still persists. > > # zonecfg -z myzone info > zonename: myzone > zonepath: /zones/myzone > brand: ipkg > autoboot: false > bootargs: > pool: > limitpriv: > scheduling-class: > ip-type: exclusive > hostid: > net: > address not specified > physical: zon0 > defrouter not specified > > >From in the zone: > # uname -a > SunOS myzone 5.11 snv_134 i86pc i386 i86xpv > # svcs ssh > STATE STIMEFMRI > offline15:15:51 svc:/network/ssh:default > # svcadm enable ssh > # svcs ssh > STATE STIMEFMRI > offline15:15:51 svc:/network/ssh:default > > # tail /var/svc/log/network-ssh\:default.log > [ Mar 23 15:15:34 Disabled. ] > [ Mar 23 15:15:34 Rereading configuration. ] > [ Mar 23 15:15:51 Enabled. ] > [ Mar 23 15:15:51 Rereading configuration. ] > > I can replicate the exact same thing using nginx. The only way to get these > services to start from within a zone is to execute the script listed in the > SMF for that service. Any help tracing down the root of this problem is > greatly appreciated. > svcadm commands are executed asynchronously, so it's not surprising to that a service is not enabled right after you run svcadm enable. if you want svcadm to wait till a service is enabled before it returns, use the -s option. ie, do: svcadm enable -s ssh also, smf won't enable services until all their dependants are online. so the likely reason you're not seeing the service enabled is because some service it depends on is offilne. whenever you have a problem with any smf service, you should run svcs -x to see what the status of the system is. so run: svcs -x ssh svcs -x so after installing your zone, did you run zlogin -C and configure the zone? if not, then smf is running sysidtool and it's waiting for your input on the console, and smf won't start ssh (and a bunch of other services) until the configuration service is finished. also, you really should never run smf methods by hand. if you do, smf doesn't know anything about them. so you wouldn't expect to see any changes in smf state. (ie, if you run the start method by hand, that won't change the service state within smf. and if you run the stop method by hand, then smf will just restart the service since as far as it's concerned the service should still be online. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] BrandZ zones running Redhat Version
On Wed, Mar 10, 2010 at 11:15:16AM -0800, Kevin Prendergast wrote: > Hi all, > > I am looking at document for BrandZ zones needing to know if BrandZ zones > support Redhat Enterprise 4.0/5.0. So far I only see RedHat 3.X support, but > it is an old document. > there is no official support for RHEL > 3.x. there is an experimental linux 2.6 support mode that you could try using to run RHEL > 3.x. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] reviews for 6933462 onu should support zones
On Wed, Mar 10, 2010 at 06:56:39PM +, John Levon wrote: > On Wed, Mar 10, 2010 at 10:46:36AM -0800, Edward Pilatowicz wrote: > > > > > > > > > > http://cr.opensolaris.org/~johnlev/onu-zones/ > > > > zoneadm list -cip will only list zones in the installed state, but > > That's not true: > > r...@hiss:~# zoneadm list -cip > 0:global:running:/::ipkg:shared > -:ozone:installed:/rpool/zones/ozone:84452639-6108-c6e3-b411-f53b9a16cc9f:ipkg:shared > -:twilight:configured:/rock/zones/twilight::ipkg:shared > > I could make it be zoneadm list -cp if it's an issue for you... > oops. my bad. re-reading of the man page has set me strait. i'm fine with either cip or cp. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] reviews for 6933462 onu should support zones
On Wed, Mar 10, 2010 at 06:10:43PM +, John Levon wrote: > On Wed, Mar 10, 2010 at 07:55:21AM -0800, Edward Pilatowicz wrote: > > > > > > > > http://cr.opensolaris.org/~johnlev/onu-zones/ > > OK please reload. > zoneadm list -cip will only list zones in the installed state, but update_zone() also check for the configured state. you probably want list -cvp ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] reviews for 6933462 onu should support zones
On Wed, Mar 10, 2010 at 03:52:31PM +, John Levon wrote: > On Wed, Mar 10, 2010 at 07:40:36AM -0800, Edward Pilatowicz wrote: > > > > > > http://cr.opensolaris.org/~johnlev/onu-zones/ > > Updated > > > hm. i actually think we'd be ok with just cloning running zones. we > > after all, we don't shut down the global zone to clone it. i guess the > > main thing that you're protecting yourself against by shutting down the > > zone is against there being a pkg(1) process running within the zone at > > the time you clone it. > > Right. I'd kind of presumed that beadm had something similarly safe for > the GZ, but maybe it doesn't. > > I don't mind removing the shutdown if people aren't wild about it. > personally, i'd leave it out. onu is for developers. if developers are running pkg commands in an ngz while running onu at the same time in the gz, well, don't do that. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] reviews for 6933462 onu should support zones
On Wed, Mar 10, 2010 at 03:13:48AM +, John Levon wrote: > On Tue, Mar 09, 2010 at 04:36:41PM -0800, Edward Pilatowicz wrote: > > > > Please can I get people to take a look at: > > > > > > http://cr.opensolaris.org/~johnlev/onu-zones/ > > > > i only have one comment. is it really possible to have a zone running > > within an alternate BE? i didn't think it was. > > Hmm. I haven't done the right thing here. What I was really trying to > say was that the zone needs to be shutdown before we clone, but of > course that happens before we iterate through the zones. I need a > two-pass approach... > hm. i actually think we'd be ok with just cloning running zones. we after all, we don't shut down the global zone to clone it. i guess the main thing that you're protecting yourself against by shutting down the zone is against there being a pkg(1) process running within the zone at the time you clone it. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] reviews for 6933462 onu should support zones
On Tue, Mar 09, 2010 at 11:12:21PM +, John Levon wrote: > > Please can I get people to take a look at: > > http://cr.opensolaris.org/~johnlev/onu-zones/ > i only have one comment. is it really possible to have a zone running within an alternate BE? i didn't think it was. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] reviews for 6933462 onu should support zones
On Tue, Mar 09, 2010 at 11:12:21PM +, John Levon wrote: > > Please can I get people to take a look at: > > http://cr.opensolaris.org/~johnlev/onu-zones/ > > BTW Ed was asking why the full refresh was needed - anyone? > that's not entirely true. ;) the full refresh is needed because we may not have the latest catalogs for all the configured publishers. what i tried to ask was: why don't the other set-publisher operations use the --no-refresh option. afaik, by default a set-publisher operation will cause us to refresh the cached publisher data, which we're going to cache anyway when we do the refresh --full. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone preconfiguration via sysidcfg fails on osol-b132
On Thu, Feb 18, 2010 at 05:14:48PM -0800, Bruno Damour wrote:
> Hello
> I'm creating a zone and after install, copying a sysidcfg.
> On zone boot and zlogin -C I still run into the prompts.
> My sysidcfg is :
>
> keyboard=French
> system_locale=en_US.UTF-8
> terminal=xterms
> network_interface=primary {
> dhcp
> protocol_ipv6=yes
> }
> security_policy=kerberos {
> default_realm=RUOMAD.LOCAL
> admin_server=rebma.ruomad.local
> kdc=rebma.ruomad.local
> }
> name_service=DNS {
> domain_name=ruomad.local
> name_server=192.168.0.150,192.168.0.1
> }
> nfs4_domain=dynamic
> timezone=Europe/Paris
> root_password=fto/dU8MKwQRI
>
> what can be wrong ?
> PS : it used to work on previous SXCE builds
>
one possibility is that opensolaris uses a different shadow file
password format (sha256 has i believe). the hash'ed password you have
listed above (which you probably shouldn't include in an email ;) looks
like an old solaris style password (crypt(3c) perhaps).
ed
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] upgrading and zones
On Sat, Feb 06, 2010 at 10:30:18AM +0100, dick hoogendijk wrote: > Going from OpenSolaris b131 to b132.. > Am I correct in this procedure: > [1] pkg image-update (with zones attached) > [2] after reboot to the new BE detach the zones > [3] zoneadm attach -u zones > > OR, do I have to detach -BEFORE- the pkg image -update? > do NOT detach BEFORE the image-update detach and attach -u AFTER the image-update ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [osol-discuss] GDM connect to GDM in a zone ?
On Mon, Feb 01, 2010 at 06:48:00PM -0800, Alan Coopersmith wrote: > Edward Pilatowicz wrote: > > if you're tring to run gdm in the zone to access local hardware > > (graphics card, keyboard, mouse, etc) that will be a difficult, since X > > now uses hal (which depends on dbus) to discover hardware. i'm not sure > > how you could work around this (my X foo is not that strong). > > Xorg only uses HAL to find input devices, and that can be overridden in > xorg.conf. > good to know. > I'd think the lack of access in a local zone to the devices in /dev that X > requires would be a much bigger obstacle (and rightly so, since letting those > into a local zone would allow that zone to take over the computer - it's bad > enough that /dev/xsvc exists at all in the global zone, much less giving a > local zone access to directly control every PCI device on the computer, > including all your NIC's and storage controllers). > very true. i made my comment because i know that in the past some folks had thrown security concerns to the wind, added a bunch of devices to a zone, and run the X server from the zone. it's not a supported config, we don't document it, we don't recommend it, i've never done it, but iirc at some point in the past people made it work. i should have qualified my statements about this configuration a bit more... ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] GDM connect to GDM in a zone ?
i've never tried this, but i'd recommend figuring out if gdm can be run as an xdmcp server. optionally, you could also run Xvnc within the zone. or you could ssh -X to the zone and remote display your apps. if you're tring to run gdm in the zone to access local hardware (graphics card, keyboard, mouse, etc) that will be a difficult, since X now uses hal (which depends on dbus) to discover hardware. i'm not sure how you could work around this (my X foo is not that strong). ed On Mon, Feb 01, 2010 at 04:54:19PM +0100, Paul van der Zwan wrote: > Is it possible to run GDM inside a zone on b131 ? I would like to have a zone > I can use to run stuff like netbeans etc in, and > I donÂ’t want to use the global zone for that. > > As far as I can tell the gdm smf service depends on dbus and that is marked > as global zone only. > One more complication is that gdm is missing the old dtlogin option to select > a remote host to connect to. > Or is that option hidden/disabled by default ? > > TIA > Paul > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zcons module failing modunload ?
On Thu, Jan 21, 2010 at 07:00:11PM +0100, Frank Batschulat (Home) wrote:
> Hiya,
>
> from the code the zcons module is supposed to be unloadable.
>
> 314 _fini(void)
> 315 {
> 316 int err;
> 317
> 318 if ((err = mod_remove(&modlinkage)) != 0) {
> 319 return (err);
> 320 }
> 321
> 322 ddi_soft_state_fini(&zc_soft_state);
> 323 return (0);
> 324 }
>
> however once it is loaded, and no zlogin, no zoneadmd running etc.
> a modunload fails with EBUSY.
>
> osoldev.batschul./tank/stuff/sw/isos.=> pfexec zlogin -C zone2
> [Connected to zone 'zone2' console]
> ~.
> [Connection to zone 'zone2' console closed]
>
> osoldev.batschul./tank/stuff/sw/isos.=> modinfo | grep zcons
> 276 f86f 1ad0 0 1 zcons (Zone console driver)
>
> osoldev.batschul./tank/stuff/sw/isos.=> pfexec modunload -i 276
> can't unload the module: Device busy
>
> is there an obvious, wellknown explanation for this fact perhaps ?
> just thought to ask before wasting time...
>
well, the module is indeed unloadable:
---8<---
edp{ro...@mcescher$ modinfo | grep zcons
edp{ro...@mcescher$ modload -p drv/zcons
edp{ro...@mcescher$ modinfo | grep zcons
301 f880a5b0 1ad0 164 1 zcons (Zone console driver)
edp{ro...@mcescher$ modunload -i 301
edp{ro...@mcescher$ modinfo | grep zcons
edp{ro...@mcescher$
---8<---
i'm guessing that there something about the way that instances of zcons
are instantiated (via libdevice`devctl_*() interfaces) that causes the
driver to be unloadable even after all known instances have been torn
down. afaik, the libdevice devctl interfaces are not really heavily
used for real device management. i think they are mostly used for
testing. so i wouldn't be shocked if there were bugs lurking there...
ed
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Tue, Jan 19, 2010 at 02:33:15PM -0700, Jerry Jelinek wrote: > On 01/19/10 14:00, Edward Pilatowicz wrote: > >>> perhaps it would make sense to add some "tokens" to the comments in > >>> brand_asm.h like: > >>> 32-BIT INTERPOSITION STACK > >>> 32-BIT LCALL/INT STACK > >>> 64-BIT INTERPOSITION STACK > >>> 64-BIT LCALL/INT STACK > >>> > >>> and then in the comments for each brand callback you could refer the > >>> reader to the appropriate tokens in brand_asm.h. > >> > >>I added this. > >> > > > >could you add references to these tokens to lx_brand_asm.s as well? > > Ed, > > Will do, sorry for not adding this yesterday. Do you want to re-review it > again after that comment change? > not really. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Mon, Jan 18, 2010 at 12:51:27PM -0700, Jerry Jelinek wrote: > Ed, > > Thanks for reviewing this, my responses are inline. > > On 01/15/10 19:26, Edward Pilatowicz wrote: > >On Thu, Jan 14, 2010 at 09:18:20AM -0700, Jerry Jelinek wrote: > >>I need a code review for my proposed fix for: > >> > >>6887823 brandz on x86 should ignore %gs and simplify brand hooks > >> > >>There is a webrev at: > >> > >>http://cr.opensolaris.org/~gjelinek/webrev.6887823/ > >> > >>This simplifies some of the handling for the %gs register, cleans up > >>the interfaces with the brand modules, and consolidates common code > >>into a single file. Although the webrev looks large, most of this is > >>because > >>of moving the common code. > >> > > > >hey jerry, > >looks good. a few comments below. > >ed > > > >-- > >usr/src/uts/i86pc/ml/syscall_asm.s > > > >- so i think the following comment is true for lcall and int syscalls on > > 32-bit kernels: > > > > * -- > > * | user's %ss | > > *|| user's %esp| > > *|| EFLAGS register| > > *|| user's %cs | > > *|| user's %eip (user return address) | > > *|| 'scratch space'| > > > > but what about sysenter syscalls? none of that stuff will be on the > > stack. (that's why BRAND_CALLBACK used to explicitly push the user > > return address onto the stack.) have you tested with sysenter > > syscalls on 32-bit kernels? > > I haven't really changed this. If you look at the original code in > syscall_asm.s, > all it was doing was re-pushing a value that was already on the stack. This > is line > 152 in the original code in syscall_asm.s. The reason this works is that the > sysenter callback doesn't use the data from the stack since the return address > is in the %edx register (see the comment on the callback in > s10_brand_asm.s or sn1_brand_asm.s). The SYSCALL_EMUL macro > expects the return address to be in a register, not on the stack. > ok. i got it this time around. man, this stuff is always confusing... > >-- > >usr/src/uts/intel/brand/*/*_brand_asm.s > > > >- you've removed all the comments that explain how the stack frame looks > > and what the assumptions are when we enter the different handlers. i > > realize this is all documented in brand_asm.h now, but now folks don't > > know how to map each of the handlers to their running conditions. it'd > > be nice if there was a comment for each handler pointing people to that > > the correct comments that apply to each handler. > > > > perhaps it would make sense to add some "tokens" to the comments in > > brand_asm.h like: > > 32-BIT INTERPOSITION STACK > > 32-BIT LCALL/INT STACK > > 64-BIT INTERPOSITION STACK > > 64-BIT LCALL/INT STACK > > > > and then in the comments for each brand callback you could refer the > > reader to the appropriate tokens in brand_asm.h. > > I added this. > could you add references to these tokens to lx_brand_asm.s as well? thanks for cleaning all this stuff up. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Thu, Jan 14, 2010 at 09:18:20AM -0700, Jerry Jelinek wrote: > I need a code review for my proposed fix for: > > 6887823 brandz on x86 should ignore %gs and simplify brand hooks > > There is a webrev at: > > http://cr.opensolaris.org/~gjelinek/webrev.6887823/ > > This simplifies some of the handling for the %gs register, cleans up > the interfaces with the brand modules, and consolidates common code > into a single file. Although the webrev looks large, most of this is because > of moving the common code. > hey jerry, looks good. a few comments below. ed -- usr/src/uts/i86pc/ml/syscall_asm.s - so i think the following comment is true for lcall and int syscalls on 32-bit kernels: * -- * | user's %ss | *|| user's %esp| *|| EFLAGS register| *|| user's %cs | *|| user's %eip (user return address) | *|| 'scratch space'| but what about sysenter syscalls? none of that stuff will be on the stack. (that's why BRAND_CALLBACK used to explicitly push the user return address onto the stack.) have you tested with sysenter syscalls on 32-bit kernels? -- usr/src/uts/intel/brand/common/brand_asm.h - could you create this file by doing an hg cp of sn1_brand_asm.h or s10_brand_asm.h? (it preserves the history and also makes it easy to see changes to the defines.) - this doesn't seem right: #ifndef _SYS_BRAND_ASM_H the SYS_ prefix is normally used by header files in /sys/. for this file you should probably have: #ifndef _BRAND_ASM_H #ifndef _COMMON_BRAND_ASM_H - this file should probably #include the files which define macros that it uses. for example, you should probably include: #include i'm sure there are others as well. -- usr/src/uts/intel/brand/*/*_brand_asm.s - you've removed all the comments that explain how the stack frame looks and what the assumptions are when we enter the different handlers. i realize this is all documented in brand_asm.h now, but now folks don't know how to map each of the handlers to their running conditions. it'd be nice if there was a comment for each handler pointing people to that the correct comments that apply to each handler. perhaps it would make sense to add some "tokens" to the comments in brand_asm.h like: 32-BIT INTERPOSITION STACK 32-BIT LCALL/INT STACK 64-BIT INTERPOSITION STACK 64-BIT LCALL/INT STACK and then in the comments for each brand callback you could refer the reader to the appropriate tokens in brand_asm.h. -- usr/src/uts/intel/brand/lx/lx_brand_asm.s - in lx_brand_int80_callback() you have: * See the comment on CALC_TABLE_ADDR in brand_asm.h for an but this function never uses CALC_TABLE_ADDR. it still does the offset calculation manually: shlq$4, %rax i think you could clean this up by changing CHECK_FOR_HANDLER and CALC_TABLE_ADDR in brand_asm.h to be de CHECK_FOR_HANDLER(scr, handler) ... cmp $0, handler(scr); /* check handler */ and: CALC_TABLE_ADDR(scr, handler) ... mov handler(scr), scr; /* get p_brand_data->handler */ \ then you also don't need this at the top of every brand: #define USP_HANDLER ... and you can use CALC_TABLE_ADDR for jump table calculations in the lx brand. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Webrev for CR 6909222
i'd probably leave out the XXX comment and instead update 6912451 to mention that part of the fix for 6912451 would involve removing the fix for 6909222 (since it would essentially be obsoleting this fix.) ed On Mon, Dec 21, 2009 at 03:46:00PM -0800, Jordan Vaughan wrote: > I need someone to review my fix for > > 6909222 reboot of system upgraded from 128 to build 129 generated > error from an s10 zone due to boot-archive > > My webrev is accessible via > > http://cr.opensolaris.org/~flippedb/onnv-s10c > > Thanks, > Jordan > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Webrev for CR 6782448
lgtm.
ed
On Mon, Dec 21, 2009 at 05:41:29PM -0800, Jordan Vaughan wrote:
> That's a good idea. I updated the webrev.
>
> Thanks,
> Jordan
>
> On 12/21/09 05:08 PM, Steve Lawrence wrote:
> >Minor nit. You could use != POC_STRING, put the Z_NO_ENTRY in the {}, and
> >put the success case after. Not a required change.
> >
> >LGTM.
> >
> >-Steve
> >
> >On Fri, Dec 18, 2009 at 07:28:52PM -0800, Jordan Vaughan wrote:
> >>I expanded my webrev to include my fix for
> >>
> >>6910339 zonecfg coredumps with badly formed 'select net defrouter'
> >>
> >>I need someone to review my changes. The webrev is still accessible via
> >>
> >>http://cr.opensolaris.org/~flippedb/onnv-zone2
> >>
> >>Thanks,
> >>Jordan
> >>___
> >>zones-discuss mailing list
> >>zones-discuss@opensolaris.org
>
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Problems when zone run
this sounds like a bug that dan price tracked down to: 6906514 sdev_attrinit ignores va_mask, leading to whacky /dev/zcons vattrs it should be fixed in snv_130. ed On Mon, Dec 21, 2009 at 11:56:20AM -0800, Eugene Turkulevich wrote: > I have two zones configured and run: ipkg zone (shared ip) and lx zone. > run: ps -aef cause some pauses during display (5 to 20 seconds) > same problem when using flash plugin in Firefox - opening page with flash > content cause Firefox freeze for 10-30 seconds. > This all when one of zones (or both) are run. > After halting both zones have no problem either with ps (no delays, works > immediately) either with Firefox (pages with flash opens without app.freeze). > > can you help me, where should I search for a problem? > > P.S.: Opensolaris snv_129. didn't remember, but think this problem appeared > in one of snv_12x builds > -- > This message posted from opensolaris.org > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Fri, Dec 18, 2009 at 08:19:02AM -0700, Jerry Jelinek wrote: > Jerry Jelinek wrote: > >Because its not right above, all of the other register values are > >also pushed on the stack, so we need to go through the SSP to get > >to the right spot. I can add a comment explaining this but the > >32bit and 64bit stacks are not identical. > > Ed, > > Actually, what I said above is not quite right. I think that > its not the other registers but the alignment that is making > the stacks different. I took another look at the AMD64 Architecture > Programmers Manual, Volume 2: System Programming manual. This is > discussed in section 8.9 Long-Mode Interrupt Control Transfers. You > can see how the stack is different vs. the discussion in section 8.7. > all the comments in our source code would seem to indicate that the stacks are the same. also, looking at the stack diagram in the v2 manual they seem to be the same to me (aisde from the obvious 32 vs 64 bit word size differences): Figure 8-9 Stack After Interrupt to Higher Privilege p280 (p320) Figure 8-14 Long-Mode Stack After Interrupt-Higher Privilege p292 (p332) also, right above figure 8-14 there is a discussion of the differences between the long mode switch vs the classic legacy switch, with the only difference being in how the SS is handled. i guess this boils down to is, is there a difference between the value of V_SSP and address of V_END, and if so why? i set some breakpoints in kmdb and compared these values and they are indeed different. looking at brand callback i can now see why, we do the following: ---8<--- #define BRAND_CALLBACK(callback_id) \ movq%rsp, %gs:CPU_RTMP_RSP /* save the stack pointer */ ;\ movq%r15, %gs:CPU_RTMP_R15 /* save %r15*/ ;\ movq%gs:CPU_THREAD, %r15/* load the thread pointer */ ;\ movqT_STACK(%r15), %rsp /* switch to the kernel stack */ ;\ ---8<--- so we're actually changing our stack pointer after entry into the kernel, so it's no longer necessarily matching the interrupt stack that the processor switched in automatically and saved the parameters on. notably we don't do this for 32-bit kernels. this means that de-referencing V_SSP is the right things todo. sorry for taking so long to understand this code... so one last comment nit and then i promise i'm done. could you update the the descriptions of the stack setup by BRAND_CALLBACK on 64-bit kernels to be more accurate for interrupt syscalls by changing: "user stack pointer" to: "user (or interrupt) stack pointer" thanks, and sorry again for the delays while i tried to understand the code better. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Thu, Dec 17, 2009 at 04:24:22PM -0700, Jerry Jelinek wrote: > Edward Pilatowicz wrote: > >to be: > >---8<--- > >/* > > * The saved stack pointer (V_SSP) points to the interrupt specific > > * state, which is saved directly above the stack contents common to all > > * callbacks. > >... > >*/ > >#define V_U_SS (V_END + (CLONGSIZE * 4)) > >#define V_U_ESP (V_END + (CLONGSIZE * 3)) > >#define V_EFLAGS(V_END + (CLONGSIZE * 2)) > >#define V_U_CS (V_END + (CLONGSIZE * 1)) > >#define V_U_EIP (V_END + (CLONGSIZE * 0)) > > > >ENTRY(sn1_brand_int91_callback) > >... > > SET_V(%rsp, 1, V_U_EIP, %r15) /* set user %eip to JMP table addr */ > > GET_V(%rsp, 1, V_URET_ADDR, %rax) /* save orig return addr in %eax */ > >---8<--- > > Ed, > > Thanks for the correction on the comment. I also updated the code as > you suggested. I'm not sure if what I have now is better than before > but its the same number of instructions and its more similar to the > the 32-bit code path (although it can't be identical). I posted a new > webrev at: > > http://cr.opensolaris.org/~gjelinek/webrev.6768950/ > > Let me know if you have any other comments. so now you have: ---8<--- #define V_U_EIP (CLONGSIZE * 0) ... GET_V(%rsp, 1, V_SSP, %rax) /* get saved stack pointer */ SET_V(%rax, 0, V_U_EIP, %r15) /* save new return addr in %eip */ ---8<--- but why can't this be identical to the 32-bit path? afaik, it seems like you could just do: ---8<--- #define V_U_EIP (V_END + (CLONGSIZE * 0)) ... SET_V(%rsp, 1, V_U_EIP, %r15) /* save new return addr in %eip */ ---8<--- why load V_SSP if we already know that the interrupt state is right on the stack above the callback arguments? (it seems we sholud just access the state directly without first loading V_SSP.) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6911329
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.
>
> thanks
> frankB
>
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6495558
lgtm. ed On Thu, Dec 17, 2009 at 07:34:08PM +0100, Frank Batschulat (Home) wrote: > Hey Ed, Steve, Jordan, Jerry, > > I got it in writing from Veritas Engineering that they do not have any > heartburn > over using "fsck -o p" on VxFS and inside the zone and also by testing in the > lab I > confirmed it behaves as expected and similar to UFS: > > > # uname -a > SunOS lab234 5.10 Generic_139555-08 sun4u sparc sun4u > > # pkginfo -l VRTSvxfs >PKGINST: VRTSvxfs > NAME: VERITAS File System > CATEGORY: system,utilities > ARCH: sparc >VERSION: 5.0,REV=5.0A55_sol > > # fsck -F vxfs -o p /dev/rdsk/c1t14d0s0 > /dev/rdsk/c1t14d0s0:file system is clean - log replay is not required > > > here's the new webrev for your consideration: > > http://cr.opensolaris.org/~batschul/onnv-vplat/ > > thanks! > frankB ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Thu, Dec 17, 2009 at 09:39:34AM -0700, Jerry Jelinek wrote: > Edward Pilatowicz wrote: > >- CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64 > > versions, it assumes the syscall number is in eax/rax, and it has a > > side effect of munging the syscall number.) how about defining just one > > version of CALC_TABLE_ADDR() as: > >---8<--- > >#define CALC_TABLE_ADDR(sysnum, rv) > >\ > > GET_P_BRAND_DATA(%rsp, 1, rv) /* get p_brand_data ptr */; > > \ > > mov SPD_HANDLER(rv), rv /* get p_brand_data->spd_handler ptr > > */;\ > > shl $4, sysnum /* syscall_num * 16 */; > > \ > > add sysnum, result /* calc JMP table address */; > > \ > > shr $4, sysnum /* syscall_num / 16 */ > >---8<--- > > Ed, > > I reworked the macros and I think its a lot cleaner now. > Let me know what you think. The new webrev is at: > > http://cr.opensolaris.org/~gjelinek/webrev.6768950/ > this looks great. things are much simpler and the callbacks are more similar. :) i only have one nit. i think the following comment is incorrect: * To 'return' to our user-space handler, we just need to place its * address into the user's %ss. it should read: * To 'return' to our user-space handler we need to update the * user's %eip pointer in the saved interrupt state. The * interrupt state was pushed onto our stack automatically when * the interrupt occured, see the comments above. actually, now that i look at it some more... i think you could make the int91 callback simpler by making it almost the same as the like the 32-bit syscall callback. after all, the stack content basically is the same in both call paths... specifically, you could change the following: ---8<--- /* * The saved stack pointer points at the state saved when we took * the interrupt: ... */ ENTRY(sn1_brand_int91_callback) ... movq%r15, %rax /* save new ret addr in %rax */ GET_V(%rsp, 1, V_SSP, %r15) /* Get saved %esp */ xchgq (%r15), %rax/* swap %rax and return addr */ ---8<--- to be: ---8<--- /* * The saved stack pointer (V_SSP) points to the interrupt specific * state, which is saved directly above the stack contents common to all * callbacks. ... */ #define V_U_SS (V_END + (CLONGSIZE * 4)) #define V_U_ESP (V_END + (CLONGSIZE * 3)) #define V_EFLAGS(V_END + (CLONGSIZE * 2)) #define V_U_CS (V_END + (CLONGSIZE * 1)) #define V_U_EIP (V_END + (CLONGSIZE * 0)) ENTRY(sn1_brand_int91_callback) ... SET_V(%rsp, 1, V_U_EIP, %r15) /* set user %eip to JMP table addr */ GET_V(%rsp, 1, V_URET_ADDR, %rax) /* save orig return addr in %eax */ ---8<--- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Wed, Dec 16, 2009 at 02:37:36PM -0700, Jerry Jelinek wrote: > Ed, > > Edward Pilatowicz wrote: > >On Wed, Dec 16, 2009 at 10:46:57AM -0700, Jerry Jelinek wrote: > >>Ed, > >> > >>I've posted an updated webrev to address your comments. > >> > >>http://cr.opensolaris.org/~gjelinek/webrev.6768950/ > >> > > > >usr/src/uts/intel/brand/sn1/sn1_brand_asm.s > > > >- i'd think the "is 0 <= syscall <= MAX" check would have to be > > done after CHECK_FOR_NATIVE(). > > It is. I added it to the CHECK_FOR_INTERPOSITION macro which is > called after the CHECK_FOR_NATIVE in the CALLBACK_PROLOGUE. > oops. your right. i was misread this. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Wed, Dec 16, 2009 at 10:46:57AM -0700, Jerry Jelinek wrote: > Ed, > > I've posted an updated webrev to address your comments. > > http://cr.opensolaris.org/~gjelinek/webrev.6768950/ > usr/src/uts/intel/brand/sn1/sn1_brand_asm.s - i'd think the "is 0 <= syscall <= MAX" check would have to be done after CHECK_FOR_NATIVE(). - CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64 versions, it assumes the syscall number is in eax/rax, and it has a side effect of munging the syscall number.) how about defining just one version of CALC_TABLE_ADDR() as: ---8<--- #define CALC_TABLE_ADDR(sysnum, rv) \ GET_P_BRAND_DATA(%rsp, 1, rv) /* get p_brand_data ptr */; \ mov SPD_HANDLER(rv), rv /* get p_brand_data->spd_handler ptr */;\ shl $4, sysnum /* syscall_num * 16 */; \ add sysnum, result /* calc JMP table address */; \ shr $4, sysnum /* syscall_num / 16 */ ---8<--- ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Tue, Dec 15, 2009 at 01:28:01PM -0700, Jerry Jelinek wrote: > Ed, > > Thanks for reviewing this. My responses to your comments are > in-line. > > Edward Pilatowicz wrote: > >On Tue, Dec 15, 2009 at 08:39:12AM -0700, Jerry Jelinek wrote: > >>I have an initial code review for the fix for bug: > >> > >>6768950 panic[cpu1]/thread=ff084ce0b3e0: syscall_asm_amd64.s:480 > >>lwp ff0756a8cdc0, pcb_rupdate != 0 > >> > >>There is a webrev at: > >> > >>http://cr.opensolaris.org/~gjelinek/webrev.6768950/ > >> > >>The code changes in the sn1 and solaris10 brands are basically > >>identical. I know there is a lot of common code there but I > >>didn't want to clutter up this bug fix with the unrelated changes > >>necessary to make the code common. I'll be addressing that with > >>a separate fix. > >> > >>My initial testing of these changes looks good but I still need > >>to run more extensive tests. > >> ... > >- prior to these changes V_URET_ADDR wasn't always set, so the different > > brand syscall callbacks would get the userland return address from > > their syscall specific locations (registers, interrupt stack, etc). but > > now since V_URET_ADDR is always set, perhaps the callback handlers could > > be made more consistent by always getting the value from the stack (ie, > > via V_URET_ADDR)? > > > >- so following up with the last comment (and getting more into potential > > comminization work) it seems to me like it might be benificial to move > > all the syscall mechanism specific handling code out of the actual brand > > callbacks and into BRAND_CALLBACK. you've already started doing this by > > having BRAND_CALLBACK be aware of how to get the userland return > > address. (prior to that it didn't have any dependancy upon the > > different syscall mechanisms, except when deciding which brand callback > > to invoke.) continuing down that path we could move all the syscall > > specific handling code into BRAND_CALLBACK. then each brand would only > > deliver a single callback which would take one parameter, the syscall > > number. it would return one value, a userland return address. then > > BRAND_CALLBACK could handle all the different syscall specific return > > paths. this would also be benificial in the future since if a new > > syscall mechanism was introduced, we wouldn't have to update any actual > > brand callbacks, just BRAND_CALLBACK. thoughts? > > For these last two I agree that there are some good opportunities here and > I was torn between doing a bunch more clean up on this and deferring that > work to the fix for: > > 6900207 code can be shared between solaris10 and ipkg brands > > Since bug 6768950 is serious and I'd like to get the fix done sooner > rather than later, I'd like to defer some of these other changes to 6900207. > I was about to start on that anyway so once 6768950 is done I'm going to > immediately start work on a bunch of ideas I have for making the code shared > and simpler. I was also going to roll a fix for: > > 6887823 brandz on x86 should ignore %gs on 64-bit kernels > > into that same set of cleanup. I definitely agree with your comments here > but I'm worried about the fix for 6768950 taking too long. > sounds good. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
On Tue, Dec 15, 2009 at 08:39:12AM -0700, Jerry Jelinek wrote:
> I have an initial code review for the fix for bug:
>
> 6768950 panic[cpu1]/thread=ff084ce0b3e0: syscall_asm_amd64.s:480
> lwp ff0756a8cdc0, pcb_rupdate != 0
>
> There is a webrev at:
>
> http://cr.opensolaris.org/~gjelinek/webrev.6768950/
>
> The code changes in the sn1 and solaris10 brands are basically
> identical. I know there is a lot of common code there but I
> didn't want to clutter up this bug fix with the unrelated changes
> necessary to make the code common. I'll be addressing that with
> a separate fix.
>
> My initial testing of these changes looks good but I still need
> to run more extensive tests.
>
this looks great. i have some initial comments.
--
usr/src/lib/brand/{sn1|solaris10}/*_brand/*/*_handler.s:
- could you update the following lines with comments:
xchgq CPTRSIZE(%rbp), %rax/* swap JMP table offset and ret addr */
shrq$4, %rax/* JMP table offset / JMP size = syscall num */
movq%rax, EH_LOCALS_GREG(REG_RAX)(%rbp) /* save syscall num */
--
usr/src/uts/i86pc/ml/syscall_asm.s:
- don't you need to update this file as well? have you tested 32-bit
kernels?
--
usr/src/uts/i86pc/ml/syscall_asm_amd64.s
- perhaps you could do the following renames:
BRAND_GET_RET_REG -> BRAND_URET_FROM_REG
BRAND_GET_RET_STACK -> BRAND_URET_FROM_INTR_STACK
- wrt this code:
cmpq$NSYSCALL, %rax /* is 0 <= syscall <= MAX? */
jbe 0f /* yes, syscall is OK */
xorq%rax, %rax /* no, zero syscall number */
it's duplicated in every brand callback right after
CALLBACK_PROLOGUE(). why not make it part of CALLBACK_PROLOGUE?
also, if the syscall num is > NSYSCALL, why not just jump to 9: and
let the normal syscall path detect and return the error?
- it seems like there should be a macro for this rough block of code
(which calculates the jmp table address):
GET_P_BRAND_DATA(%esp, 1, %edx);/* get p_brand_data ptr */
movlSPD_HANDLER(%edx), %edx /* get p_brand_data->spd_handler ptr */
shll$4, %eax
addl%eax, %edx /* we'll return to our handler */
- prior to these changes V_URET_ADDR wasn't always set, so the different
brand syscall callbacks would get the userland return address from
their syscall specific locations (registers, interrupt stack, etc). but
now since V_URET_ADDR is always set, perhaps the callback handlers could
be made more consistent by always getting the value from the stack (ie,
via V_URET_ADDR)?
- so following up with the last comment (and getting more into potential
comminization work) it seems to me like it might be benificial to move
all the syscall mechanism specific handling code out of the actual brand
callbacks and into BRAND_CALLBACK. you've already started doing this by
having BRAND_CALLBACK be aware of how to get the userland return
address. (prior to that it didn't have any dependancy upon the
different syscall mechanisms, except when deciding which brand callback
to invoke.) continuing down that path we could move all the syscall
specific handling code into BRAND_CALLBACK. then each brand would only
deliver a single callback which would take one parameter, the syscall
number. it would return one value, a userland return address. then
BRAND_CALLBACK could handle all the different syscall specific return
paths. this would also be benificial in the future since if a new
syscall mechanism was introduced, we wouldn't have to update any actual
brand callbacks, just BRAND_CALLBACK. thoughts?
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6495558
so just one question. the '-p' preen option is only documented in the fsck_ufs(1m) man page, and not in fsck(1m). so i'm wondering is are there zones which may be installed on other filesystems which supply an fsck utility which may not support the preen option? (or perhas '-p is defined as something else for those versions of fsck?) specifically vxfs comes to mind since i know that some s10 deployments use that. ed On Fri, Dec 11, 2009 at 02:24:49PM +0100, Frank Batschulat (Home) wrote: > friends, may I request code review for the earth-shattering fix to: > > 6495558 zoneadm -z boot should not only check but repair filesystems > http://cr.opensolaris.org/~batschul/onnv-vplat/ > > backround: > > Evaluation > > when booting a zone, zoneadm ( ie. vplat.c:dofsck() ) should perform the same > tasks as the /usr/sbin/mountall script, > which does a 'is suitable for mounting' (fsck -m) check first, followed by a > preen fsck (fsck -p) if the former failed. > > the obvious quick fix would be to change the code in vplat.c:dofsck() > > 825 argv[0] = "fsck"; > 826 argv[1] = "-m"; > 827 argv[2] = (char *)rawdev; > 828 argv[3] = NULL; > 829 > 830 status = forkexec(zlogp, cmdbuf, argv); > 831 if (status == 0 || status == -1) > 832 return (status); > 833 zerror(zlogp, B_FALSE, "fsck of '%s' failed with exit status > %d; " > 834 "run fsck manually", rawdev, status); > 835 return (-1); > > to always just run fsck in preen mode (shouldn't cause any real problem) or > fork off a 2nd fsck in preen mode > if the first fsck -m failed. > > actually the fix will be to just execute fsck in preen mode (fsck -p) rather > then > doing the 'is suitable for mounting' and preen fsck dance. if the former > fails, > the latter will have to be done anyways. the latter however kind of implies > the former. > > thanks! > -- > frankB > > It is always possible to agglutinate multiple separate problems > into a single complex interdependent solution. > In most cases this is a bad idea. > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Solaris10-Branded Zones Webrev: CR 6882732
On Wed, Dec 09, 2009 at 02:54:05PM -0800, Jordan Vaughan wrote: > I need someone to review my fix for > > 6882732 unpacking archive with extended file attributes reports errors > > The webrev is accessible via > > http://cr.opensolaris.org/~flippedb/onnv-s10c > lgtm. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris 10 branded zone
On Tue, Dec 08, 2009 at 09:31:55AM -0800, xx wrote: > i'm still not doing something right: > > init...@dogpatch:~# pkg install SUNWs10brand > Creating Plan > pkg: The following pattern(s) did not match any packages in the current > catalog. > Try relaxing the pattern, refreshing and/or examining the catalogs: > SUNWs10brand > > init...@dogpatch:~# pkg info -r "*" 2>&1 | grep brand > pkg://development/SUNWipkg-brand > init...@dogpatch:~# pkg info -r "*" 2>&1 | grep s10 > init...@dogpatch:~# pkg publisher > PUBLISHER TYPE STATUS URI > development (preferred) origin online > http://pkg.opensolaris.org/dev/ > extra origin online > https://pkg.sun.com/opensolaris/extra/ > opensolaris.org origin online > http://pkg.opensolaris.org/release/ it's also a bug to be subscribed to both the "release" and the "dev" repos. you can't be running both an official release and a dev build at the same time. you need to remove the "release" repo. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on shared storage proposal
On Fri, Nov 27, 2009 at 02:47:37PM -0800, Frank Batschulat wrote: > Hey Ed, addition to my previous posting as I just noticed something I've > totally > forgotten about > > > afaik, determining the mount point should be pretty > > strait forward. i was planning to get a list of all the shares > > exported by the specified nfs server, and then do a strncmp() of all the > > exported shares against the specified path. the longest matching share name > > is the mount path. > > > > for example. if we have: > > nfs://jurassic/a/b/c/d/file > > > > and jurassic is exporting: > > jurassic:/a > > jurassic:/a/b > > jurassic:/a/b/c > > > > then our mount path with be: > > /var/zones/nfsmount/jurassic/a/b/c > > > > and our encapsulated zvol will be accessible at: > > /var/zones/nfsmount/jurassic/a/b/c/d/file > > > > afaik, this is acutally the only way that this could > > be implemented. > > I just recognized (my bad) that the SO-URI of > 'nfs://[:port]/'. > is actually compliant to the WebNFS URL syntax of RFC 2224 / RFC 2054 / RFC > 2055 > ie.one could directly mount that. > > so it looks like we can avoid all the parsing handstands and directly mount > such an URL aka. SO-URI if the server does support public file handles. > > I'll look into the URL mount schema and requirements in a bit more detail > to discover potential problems laying around, generic support and > availability. > > ideally it should be something that should work with almost every NFS server > and > presumably without much setup on the server side in order to serve our > NFS implementation independend needs. > sounds good. in the future i'll make sure to read all your follow up emails before replying to your initial emails. ;) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on shared storage proposal
On Fri, Nov 27, 2009 at 09:12:33AM -0800, Frank Batschulat wrote: > Hey Ed, I want to comment on the NFS aspects involed here, > > On Thu, May 21, 2009 at 3:55 AM, Edward Pilatowicz wrote: > > > >well, it all depends on what nfs shares are actually being exported. > > I definitively think we do want to abstain from that much programmatic > attempts inside the Zones framework on making assumptions about what > an NFS server does export, how the NFS servers exported namespace > may look like and how the NFS client (who's running the Zone) > handles those exports upon access as opposed to explicit mounting. > > It is merely okay for the NFS v2/v3 (and their helper) protocols world > but it is not always adequate for the V4 protocol and all the work/features > in V4 and V4.1 towards a unified, global namespace. > > I'll show why in the context of V4 on the examples you > mentioned below. > > >if the nfs server has the following share(s) exported: > > > >nfsserver:/vol > > > >then you would have the following mount(s): > >/var/zones/nfsmount/zone1/nfsserver/vol > >/var/zones/nfsmount/zone2/nfsserver/vol > >/var/zones/nfsmount/zone3/nfsserver/vol > > > >if the nfs server has the following share(s) exported: > > > >nfsserver:/vol/zones > > > >then you would have the following mount(s): > >/var/zones/nfsmount/zone1/nfsserver/vol/zones > >/var/zones/nfsmount/zone2/nfsserver/vol/zones > >/var/zones/nfsmount/zone3/nfsserver/vol/zones > > in those 2 examples, we'd have to consider how the > V4 server constructs it's pseudo namespace starting > at the servers root, including what we call pseudo exports > that build the bridge to the real exported share points > at the server and how the V4 client may handle this. > > for instance, on the V4 server the export: > > /vol > > may (and probably will) have different ZFS datasets > that host our zones underneath /vol eg.: > > /vol/zone1 > /vol/zone2 > /vol/zone3 > > since they are separate ZFS datasets, we would > cross file system boundaries while traversing from > the exported servers root / over the share point /vol > down to the (also presumably exported, otherwise it > wouln't be usefull in our context anyways) share points > zone1/zone2/zone3. > > We'll distingish between the different file systems > based on the FSID attribute, if it changes, we'd cross > server file system boundaries. > > With V2/V3 that'd stop us and the client can not travel into > the new file system below the inital mount and a separate mount > would have to be performed (unless we've explicitely mounted > the entire path of course) > > However, with V4, the client has the (in our implementation) > so called Mirror Mount feature. That allows the client > to transparantly mount those new file systems on access below > the starting share point /vol (provided they are shared as well) > and make them immediately visible without requiring the user > for perform any additional mounts. > > Those mirror mounts will be done automatically by our V4 client > in the kernel as it detects it'd cross server side file system > boundaries (based on the FSID) on any access other then > VOP_LOOKUP() or VOP_GETATTR(). > > Ie. if the global zone did already have mounted > > server:/vol > > an attempt by the zone utilities to access (as opposed to > explicit mounting) of > > server:/vol/zone1 > > will automatically mount server:/vol/zone1 into > the clients namespace and you'd get on the client > (nfsstat -m) 2 mounts: > > server:/vol (already existing regular mount) > server:/vol/zone1 (the mirror mount done by the client) > > if we'd really perform a mount though, that'd just induce > the mount of > > server:/vol/zone1 > > into the clients namespace running the zone. > > With the advent of the upcomming NFS v4 Referrals support > in the V4 server and V4 client, another 'automatism' > in the client can possibly change our observation of > the mounted server exports on the client running the zone. > > On the V4 server (that is hosting our zone image) the administrator > might decide to relocate the export to a different server and > then might establish a so called 'reparse point' (in essence > a symlink containing special infos) that will redirect a client > to a different server hosting this export. > > NB: other Vendors NFS servers might hand out referrals to > NB2: the same feature will be supported by our CIFS client > > The V4 client can get a specific referral event (NFS4ERR_MOVED) > on VOP_LOOKUP(), VOP_GETATTR(
Re: [zones-discuss] call to zoneadmd failed error
On Sun, Nov 22, 2009 at 11:52:24PM -0800, Daniel Dinu wrote: > Hello, > > Yes - /zone1 is a separate filesystem. > > r...@server.com#zfs list > NAME USED AVAIL REFER MOUNTPOINT > rpool 12.7G 216G81K /rpool > rpool/ROOT5.30G 216G19K legacy > rpool/ROOT/opensolaris26.9M 216G 4.84G / > rpool/ROOT/opensolaris-1 5.27G 216G 4.96G / > rpool/dump1.49G 216G 1.49G - > rpool/export 3.99G 216G21K /export > rpool/export/home 3.99G 216G21K /export/home > rpool/export/home/kido3.99G 216G 3.99G /export/home/kido > rpool/newclone 17K 216G20K /newclone > rpool/newfs 20K 15.0G20K /newfs > rpool/swap1.49G 217G 101M - > rpool/zone1474M 216G21K /zone1 > rpool/zone1/ROOT 474M 216G19K legacy > rpool/zone1/ROOT/zbe19K 216G19K legacy > rpool/zone1/ROOT/zbe-1 19K 216G19K legacy > rpool/zone1/ROOT/zbe-2 237M 216G 237M legacy > rpool/zone1/ROOT/zbe-3 237M 216G 237M legacy > r...@server.com:~# zfs list -t all -r rpool/zone1 > NAME USED AVAIL REFER MOUNTPOINT > rpool/zone1 474M 216G21K /zone1 > rpool/zone1/ROOT 474M 216G19K legacy > rpool/zone1/ROOT/zbe 19K 216G19K legacy > rpool/zone1/ROOT/zbe-119K 216G19K legacy > rpool/zone1/ROOT/zbe-2 237M 216G 237M legacy > rpool/zone1/ROOT/zbe-3 237M 216G 237M legacy > > > I guess zbe-n were created during my several attempts to create the zone... > yep, a zbe filesystem is normally created during an install. but normally we detect that there is an existing filesystem for the zone so we shouldn't be creating new ones. we keep track of the zbe by using a uuid. so could you display the following zfs properties? zfs get -r org.opensolaris.libbe:uuid rpool/ROOT zfs get -r org.opensolaris.libbe:parentbe rpool/zone1/ROOT zfs get -r org.opensolaris.libbe:active rpool/zone1/ROOT > I noticed the mountpoint is set to "legacy" . Is this the way it should be? > the "legacy" mountpoint is correct. the root of the zone will actually be mounted when you try to boot the zone. it would be interesting to know if you are able to zoneadm(1m) "ready" the zone. (booting is really two steps, and implicit "ready" and then a "boot".) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] call to zoneadmd failed error
On Fri, Nov 20, 2009 at 06:26:06AM -0800, Daniel Dinu wrote: > Hi guys, > > I'm new to opensolaris; I installed opensolaris a few days ago and tried to > create a new zone, but installation failed. > Here's what I've done: > > # uname -a > SunOS server.com 5.11 snv_111b i86pc i386 i86pc Solaris > > # zonecfg -z zone1 > zone1: No such zone configured > Use 'create' to begin configuring a new zone. > zonecfg:zone1> create > zonecfg:zone1> set zonepath=/zone1 > zonecfg:zone1> add net > zonecfg:zone1:net> set address=10.171.122.208 > zonecfg:zone1:net> set physical=bge0 > zonecfg:zone1:net> set defrouter=10.171.120.1 > zonecfg:zone1:net> end > zonecfg:zone1> set pool=pool_default > zonecfg:zone1> verify > zonecfg:zone1> commit > zonecfg:zone1> exit > r...@server.com:~# zoneadm -z zone1 install >Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/). >Image: Preparing at /zone1/root. >Cache: Using /var/pkg/download. > Sanity Check: Looking for 'entire' incorporation. > Installing: Core System (output follows) > DOWNLOADPKGS FILES XFER (MB) > Completed 20/20 3021/3021 42.55/42.55 > > PHASEACTIONS > Install Phase 5747/5747 > Installing: Additional Packages (output follows) > DOWNLOADPKGS FILES XFER (MB) > Completed 37/37 5598/5598 32.52/32.52 > > PHASEACTIONS > Install Phase 7329/7329 > > Note: Man pages can be obtained by installing SUNWman > Postinstall: Copying SMF seed repository ... done. > Postinstall: Applying workarounds. > Done: Installation completed in 930.558 seconds. > > Next Steps: Boot the zone, then log into the zone console > (zlogin -C) to complete the configuration process > r...@server.com:~# zoneadm -z zone1 boot > zoneadm: zone 'zone1': call to zoneadmd failed > r...@server.com:~# zoneadm -z zone1 boot > zoneadm: zone 'zone1': call to zoneadmd failed > r...@server.com:~# zoneadm list -iv > ID NAME STATUS PATH BRANDIP >0 global running/ native > shared >- zone1installed /zone1 ipkg > shared > r...@server.com:~# > > I checked the location where the install should occur, but there;s nothing > there: > # ls -lR /zone1/ > /zone1/: > total 2 > drwxr-xr-x 2 root root 2 2009-11-20 14:59 root > > /zone1/root: > total 0 > > I couldn't find any log relevant log file. > Of course, before posting I searched the net; although this error seems > pretty common, I couldn't find any similar situation... > > Any help, guiding steps, pointing to log files etc. would be much > appreciated.. > zones can't live in the same filesystem as the root filesystem, so presumably /zone1 is a mountpoint of another zfs filesystem? (although i thought we detected such a situation and emitted an error.) also, by default zones aren't mounted in opensolaris. so assuming that /zone1 is a zfs filesystem then what would be interesting is todo: zfs list -t all -r ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone 'from scratch'
On Fri, Nov 20, 2009 at 02:48:56PM -0500, David Pipes wrote: >I've been told there is a demo environment in the Solaris 8 container >download, >I suspect it's time-limited or something. Maybe the Solaris 9 container it is not time limited. there is no drm or licensing enforcement mechanism. >dl has a >similar piece? > you can download s8/s9 containers here: http://www.sun.com/software/solaris/containers/getit.jsp sample s8/s9 flar archives are provided in the download for testing and validation purposes. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone 'from scratch'
On Fri, Nov 20, 2009 at 09:22:56AM -0800, nikolay wrote: > I have a workstation with Solaris 10 pre-installed. Also I have CD's set with > Solaris 9 distribution. How can I make a solaris 9 zone with 'naked' solaris > 9 OS not having prepared OS image? you can't. you can only install an s9 container using an existing s9 installed system image. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] quick bug fix webrev...
On Thu, Nov 19, 2009 at 09:16:45PM -0800, 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" > thanks for all the reviews. also, for the morbidly curious, i filed the following followup bug: 6903488 branded zones without a kernel module are not actually branded ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] quick bug fix webrev...
On Thu, Nov 19, 2009 at 11:12:48PM -0800, Dan Price wrote: > 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. > done. > 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... > the "default brand" is currently only used within the global zone. it's generally useful if we want to lookup zone configuration options that are not associated with any particular zone. currently this is only used when setting up scratch zones. (since in that case we're going to be running an image in sync with the global zone, and hence we don't want to use a brand configuration that won't work with bits that aren't in sync with the global zone.) we could remove calls to this interface from within non-global zones, but i think it's much better/easier just to make the interface work within a zone and say that within a zone "default" is the current zones brand. otherwise we'll just end up with more bugs like this one where someone adds a call to the interface, does some testing (but doesn't hit the case where the interface is called within a zone), and then ends up with broken code. the current failure is caused by the fact that i added a call to this inteface in the beginning of zoneadm. in the global zone we need to know the default_brand in a few different places, and since the default brand will never change over the life of the zoneadm invocation, it seemed easiest to initialize a global once with this value. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] quick bug fix webrev...
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" thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] one line webrev...
hey all, so with my recent zoneadm mount putback i broke the native brand on nevada. i've got a webrev with the one line fix here: http://cr.opensolaris.org/~edp/onnv-zmount2 6898056 native zones no longer boot: zone 'public': missing or invalid brand ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] webrev for on-nightly zone install fix
hey all, i've got a webrev that needs review: http://cr.opensolaris.org/~edp/pkg-on-nightly/ it's a fix for: 11392 'zoneadm .. install' only uses preferred publisher http://defect.opensolaris.org/bz/show_bug.cgi?id=11392 this fix let's me install zones on systems that are running on-nightly ips bits. the fix is pretty well explained in my last comment in the bug report. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updated webrev...
On Wed, Oct 28, 2009 at 08:59:15AM +0100, casper@sun.com wrote: > > >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. > > > Agreed; yield() should not be used at all in a loop (or perhaps never: you > should assume that yield() is a no-op). Specifically, it may cause the > CPU to run at the highest frequency. > > (poll(NULL, 0, 100); sleeps 0.1 second) > please see my other email. this code is only invoked when zoneadmd is exiting because a zone is halting. it's a rare case. also, zoneadm is very aggressive in calling zoneadmd. it can invokes door calls in a loop. so in this case we WANT to be aggressive. we WANT to exit ASAP. if we had fast cpus and zoneadm can call into the door faster than every .1 seconds, polling won't work. yield() really is the right solution here. (yield() is not a no-op. it's unschedule me so someone else can run. thats exactly the semantic we want here.) i don't think poll() is a good option here. the other alternatives are: - redesign the exit dance between zoneadm and zoneadmd - just exit without bothering to fdetach() the door and let any subsequent zoneadmd instance deal with the need to fdetach(). ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updated webrev...
On Tue, Oct 27, 2009 at 07:27:10PM -0700, Dan Price wrote:
> 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)...
>
well, i was running zts and i discovered that zoneadm and zoneadmd were
both spinning. after doing a code inspection of zoneadmd i determined
that the only way we could get into this situation was for fdetach() to
return EBUSY. so i wrote a test program to verify that it was possible
for fdetach() to return EBUSY for a door. (the test program is attached
to the bug report.)
so i just ran my test program again after activating the following
dtrace probe:
---8<---
e...@mcescher$ dtrace \
-n 'fbt::vn_vfswlock:entry/execname == "a.out"/{printf("0x%x", arg0)}' \
-n 'fbt::vn_vfswlock:return/execname == "a.out"/{printf("0x%x", arg1)}' \
-n 'fbt::set_errno:entry/execname == "a.out" && arg0 == 16/{stack(20);
exit(0);}'
...
1 21969vn_vfswlock:entry 0xff04f3139600
1 21970 vn_vfswlock:return 0x10
1 19881 set_errno:entry
genunix`umount2_engine+0xa5
genunix`umount2+0x142
unix`_sys_sysenter_post_swapgs+0x149
---8<---
so vn_vfswlock() (called from umount2_engine()) is failing here:
---8<---
if (rwst_tryenter(&vpvfsentry->ve_lock, RW_WRITER))
return (0);
---8<---
ed
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] updated webrev...
On Tue, Oct 27, 2009 at 05:07:08PM -0700, Dan Price wrote: > 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 > done. > 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. > 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.) 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). ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] updated webrev...
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. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] review needed for scratch zone mount fix
nice catch. i put it there because of it's similarity with zonecfg_default_privset(), but it doesn't sync with the comments above. i've moved it to the "higher-level routines" section as you suggested. thanks ed On Mon, Oct 19, 2009 at 02:02:13PM -0700, Jordan Vaughan wrote: > Hi Ed, > > usr/src/head/libzonecfg.h > > This isn't critical, but shouldn't zonecfg_default_brand() be declared > somewhere other than the group of "privilege-related functions"? Perhaps > it should go under "higher-level routines". > > Other than that, this looks good to me. > > Thanks, > Jordan > > > On 10/16/09 05:12 PM, Edward Pilatowicz wrote: >> hey all, >> >> so it seems that in opensolaris b120 i broke scratch zones with the >> following fix: >> >> 9392 native zones should fail to install on opensolaris >> >> so now i've got a fix for that breakage: >> >> http://cr.opensolaris.org/~edp/onnv-zmount/ >> 6889379 zoneadm mount fails on opensolaris >> >> the basic problem was that a bunch of the zones code used for mounting >> scratch zones would attempt to use the "native" brand parameters. when i >> removed the "native" brand i broke that code. so now i'm fixing that >> code by introducing the concept of a default brand. in most places >> where we used to hard code "native", i've changed it so that we do a >> lookup to determine the default brand name, and then use that in place >> of "native". currently the default brand is defined as whatever is the >> brand specified in /etc/zones/SUNWdefault.xml. (which on opensolaris >> means we default to "ipkg".) >> >> thanks >> ed >> ___ >> zones-discuss mailing list >> zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] review needed for scratch zone mount fix
hey all, so it seems that in opensolaris b120 i broke scratch zones with the following fix: 9392 native zones should fail to install on opensolaris so now i've got a fix for that breakage: http://cr.opensolaris.org/~edp/onnv-zmount/ 6889379 zoneadm mount fails on opensolaris the basic problem was that a bunch of the zones code used for mounting scratch zones would attempt to use the "native" brand parameters. when i removed the "native" brand i broke that code. so now i'm fixing that code by introducing the concept of a default brand. in most places where we used to hard code "native", i've changed it so that we do a lookup to determine the default brand name, and then use that in place of "native". currently the default brand is defined as whatever is the brand specified in /etc/zones/SUNWdefault.xml. (which on opensolaris means we default to "ipkg".) thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
On Tue, Oct 06, 2009 at 12:18:21PM -0600, Jerry Jelinek wrote: > Peter Memishian wrote: >> > also, i would have though you'd commited to doing this work when you >> > decided to fork the sn1 brand code instead of making it common. >> >> I was wondering about this too. Indeed, there seems be a sizeable amount >> of duplicated code now. Why is this the right design? > > Because the sn1 brand is an internal brand for testing > and is not delivered to customers. Once the solaris10 > brand is integrated, the sn1 brand will no longer serve > its original role and could even be removed from the source > tree if we wanted to. > really? i'd have to disagree. i was actually expecting that when nevada dies we'd have to update the sn1 brand to work on opensolaris. i always thought you forked the code because that was faster than re-factoring it to be common. the sn1 brand is still the ideal method for testing the brandz framework itself. using the s10 brand to test the brandz framework is ok, but then you're also testing the s10 emulation layer, and that emulation is far from complete. (witness all the currently unsupported s10 functionality.) as an example, take a look at todds current bug. from todds (a developers) perspective, i think it'd be much better to reproduce the problem, debug it, fix it, and test it on the sn1 brand than on the s10 brand. the sn1 brand makes brandz framework development and regression testing easier for developers. (it's actually a bug, and a dis-service to ourselves, that we never integrated it into our automated zones testing.) the fact that the sn1 code is also for the most part duplicated in the s8 and s9 brands is also lousy. hopefully no one ever makes a successfull business case for porting those to opensolaris. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
On Tue, Oct 06, 2009 at 12:15:23PM -0600, Jerry Jelinek wrote: > Ed, > > Edward Pilatowicz wrote: >> On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote: >>> Ed, >>> >>> Thanks for reviewing this again. I took most of your >>> input. For the questions you had or the things I >>> didn't take, I have responded below. >>> >>> Edward Pilatowicz wrote: >>>> - could you propegate back your common changes to the original file? >>> I don't want to complicate this project with the additional >>> changes to the sn1 brand and the corresponding additional testing. >>> I filed bug: >>> >>> 6888642 sn1 brand cleanup >>> >>> so that we can track that work as a separate integration. >>> >> >> sigh. are you commiting to this work? the sn1 brand always get's >> neglected (says the guy who spent too much time fixing it up to be a >> real brand). > > Sure. I just don't want these coupled together. > then please make sure to update the bug with a detailed list of all the differences between the two. (should be easy since i already hilighted all the differences in my code review comments.) >>>> -- >>>> usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c >>>> >>>> - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5 >>>> used instead of S10_TRUSS_POINT_3? >>> Because the first 3 parameters are required for a truss point. That is, >>> S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which >>> is the number of parameters we're passing. >>> >> >> but i thought the caller passed in 4 parameters. (in addition to the >> cmd.) why are you not printing out "buf" and "bufsize"? > > Those parameters aren't that useful for debugging. I can add them > if you'd like. > yes please. otherwise some anal retentive person who is debugging a problem will get distracted by the fact that the buf pointer and size values are invalid. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote: > Ed, > > Thanks for reviewing this again. I took most of your > input. For the questions you had or the things I > didn't take, I have responded below. > > Edward Pilatowicz wrote: >> - could you propegate back your common changes to the original file? > > I don't want to complicate this project with the additional > changes to the sn1 brand and the corresponding additional testing. > I filed bug: > > 6888642 sn1 brand cleanup > > so that we can track that work as a separate integration. > sigh. are you commiting to this work? the sn1 brand always get's neglected (says the guy who spent too much time fixing it up to be a real brand). also, i would have though you'd commited to doing this work when you decided to fork the sn1 brand code instead of making it common. besides, aside from the elfexec changes all the changes are Makefile related, right? that's not a whole lot of extra testing. >> - there is duplicated code here from the pkg(5) brand common.ksh. perhaps >> the common code should go in /usr/lib/brand/shared/common.ksh? >> fail_fatal() >> get_zonepath_ds() >> get_active_ds() > > get_zonepath_ds() is not common since the ipkg brand has the additional > dependency on the global zone BE which does not exist for the solaris10 > brand. > ok. but if get_zonepath_ds() is not common, then why are you adding it to usr/src/lib/brand/native/zone/common.ksh? >> - in create_active_ds(), newly created datasets will have different >> values from pre-existing datasets. new datasets will inherit the >> mountpoint and zoned properties while existing datasets will have >> these explicitly set. (if your worried about these having incorrect >> values for existing datasets, perhaps you should re-inherit them >> instead of setting them.) > > We don't want to inherit these, we want to set them. The values will > change as the zone gets detached/attached so we always want to set > the values we need. > i dont' understand, currently we don't always set these values. if we do a fresh install, "mountpoint" and "zoned" are inherited: ---8<--- e...@mcescher$ zfs get -o source mountpoint,zoned export/zones/z1/ROOT/zbe SOURCE inherited from export/zones/z1/ROOT inherited from export/zones/z1/ROOT ---8<--- so why the difference for attached zones? for attached zones you "zfs set" the values above. why not just "zfs inherit" instead. (you already explicitly set them for the ROOT dataset, so they would be correct.) >> - in sysunconfig_zone(), if the zone never gets to single-user mode then >> should we return 1 instead of charging ahead and trying to run >> sys-unconfig? (since in that case sys-unconfig could hang.) > > I think its worth trying anyway since there may be something else > going on and we don't know for sure if sys-unconfig will hang. > could you add comments explaining this? >> -- >> usr/src/lib/brand/solaris10/s10_support/s10_support.c > >> - get_image_emul_version(), does an == comparison on the KU. that means >> whenever a new KU is release, we'll need to update this code. does >> that mean you forsee verification test runs for each s10 KU, and a >> subsequent update to this code once the tests complete? if so please >> add comments to the code explaning this. > > No, thats incorrect. A new KU will always incorporate the old KU. > For example, if you were running the S10u6 KU and then installed > the S10u9 KU, your system would then look like it had the u6, u7, > u8 and u9 KUs installed. > please add comments explaining this. >> -- >> usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c >> >> - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5 >> used instead of S10_TRUSS_POINT_3? > > Because the first 3 parameters are required for a truss point. That is, > S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which > is the number of parameters we're passing. > but i thought the caller passed in 4 parameters. (in addition to the cmd.) why are you not printing out "buf" and "bufsize"? ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
i've finished looking through the rest of the files and my comments are attached. ed On Tue, Sep 29, 2009 at 05:09:26PM -0600, Jerry Jelinek wrote: > Edward Pilatowicz wrote: >> - also, since the s10 brand is derived from the sn1 brand, could you >> please ensure that all the new s10 brand that are being created are >> derived from the corresponding sn1 brand files? ie, the s10 brand files >> which are derived from sn1 brand files should be created via "hg cp ..." >> instead of "cp ...; hg new ..." (this will preserve the sn1 brand >> revision history when looking at s10 brand files.) >> >> additionally, danek has an enhanced version of webrev where, if the s10 >> branded files are "hg cp"d from the sn1 files, we'll just see the deltas >> against the sn1 files (instead of having all these files show up as new). > > I've generated a new webrev using some improvements Ed made to > webrev. This, combined with the use of 'hg copy', make the > webrev much smaller and easier to review. I've uploaded > the new webrev to: > > http://cr.opensolaris.org/~gjelinek/webrev.646/ > > Please get me any comments by the end of the week so that we > have time to make the necessary changes and rerun the tests before > we integrate. > > Thanks, > Jerry -- usr/src/lib/brand/solaris10/s10_support/s10_support.c - s10_err() should probably write the error to stderr instead of stdout. - s10_verify(), you don't support adding sound devices, but you do support other devices? seems kinda arbitrary? perhaps a comment explaining this would help? - s10_verify(), why are zfs fsent entries experimental? zone administrators don't have any abilities to manipulate properties on those types of zfs filesystem. from the zones perspective they are treated the same as ufs, tmpfs, vxfs, etc. only POSIX operations are permitted on these filesystems. (afaik.) - get_image_emul_version(), doesn't this essentially duplicate the functionality provided by the /usr/lib/brand/solaris10/version file delivered via s10? in both cases we're deriving an emulation version based on the s10 bits within the zone. could you explain why this is necessary and under what conditions each versioning mechanism will be used? - get_image_emul_version(), does an == comparison on the KU. that means whenever a new KU is release, we'll need to update this code. does that mean you forsee verification test runs for each s10 KU, and a subsequent update to this code once the tests complete? if so please add comments to the code explaning this. -- usr/src/lib/brand/solaris10/zone/clone.ksh - you should check for errors from mkdir and chmod -- usr/src/lib/brand/solaris10/zone/p2v.ksh - shouldn't safe_rm() go into /usr/lib/brand/shared/common.ksh - should safe_rm return an error if the object exists but isn't a file? - please check error codes from mktemp - please check error codes from chown and chmod. -- usr/src/lib/brand/solaris10/zone/image_install.ksh - trap_cleanup(), comment talks about IPDs - why set EXIT_CODE=$ZONE_SUBPROC_OK at 249? if we ctrl-C the process after this and the zone won't have the install log in it but it will still be listed as installed. - can't you use safe_dir() to verify /var in the zone? -- usr/src/lib/brand/solaris10/zone/attach.ksh - trap_cleanup(), comment talks about IPDs - you have the following comment: # # Try to create a zfs dataset for the zonepath (this is automatically # done by zoneadm for the install subcommand but not for attach). # why not change zoneadm attach to be consistent with install and create these dataset when possible. (seems like that would benifit the ipkg brand as well.) - same comments about zfs property inheritance vs explicit setting that i made about create_active_ds() in common.ksh apply here. actually, why can't you just add an argument to create_active_ds() to indicate if the datasets must already exist, and then just invoke that here? - the two /var/log comments i made about image_install.ksh apply here. so why not create a function that does all the /var/log checks and copies the log files into the zone and put it in common.ksh? -- usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c - the d, s, and val parameters should have parens around them in the zfs_assign macro. - there is nothing zfs specified about the zfs_assign macro. this would be more appropritely names struct_member_assign or struct_member_copy. - since the zc_name, zc_value, and zc_string are all arrays embedded within the zfs_cmd_t, there is no reason to use uucopy to access them individually. - given the level of indentation in s10_audits
Re: [zones-discuss] s10 brand Phase I webrev
i'm not done yet, but i've attached what i've got so far. ed On Tue, Sep 29, 2009 at 05:09:26PM -0600, Jerry Jelinek wrote: > Edward Pilatowicz wrote: >> - also, since the s10 brand is derived from the sn1 brand, could you >> please ensure that all the new s10 brand that are being created are >> derived from the corresponding sn1 brand files? ie, the s10 brand files >> which are derived from sn1 brand files should be created via "hg cp ..." >> instead of "cp ...; hg new ..." (this will preserve the sn1 brand >> revision history when looking at s10 brand files.) >> >> additionally, danek has an enhanced version of webrev where, if the s10 >> branded files are "hg cp"d from the sn1 files, we'll just see the deltas >> against the sn1 files (instead of having all these files show up as new). > > I've generated a new webrev using some improvements Ed made to > webrev. This, combined with the use of 'hg copy', make the > webrev much smaller and easier to review. I've uploaded > the new webrev to: > > http://cr.opensolaris.org/~gjelinek/webrev.646/ > > Please get me any comments by the end of the week so that we > have time to make the necessary changes and rerun the tests before > we integrate. > > Thanks, > Jerry -- usr/src/lib/brand/solaris10/s10_brand/Makefile - could you propegate back your common changes to the original file? -- usr/src/lib/brand/solaris10/s10_support/Makefile - instead of: ../../../../uts could you do: $(SRC)/uts - could you propegate back your common changes to the original file? -- usr/src/lib/brand/solaris10/librtld_db/Makefile.com - could you propegate back your common changes to the original file? -- usr/src/lib/brand/solaris10/zone/config.xml - could you propegate back your common changes to the original file? -- usr/src/lib/brand/solaris10/zone/platform.xml - could you propegate back your common changes to the original file? -- usr/src/uts/common/brand/solaris10/s10_brand.c - in s10_getattr() and s10_setattr(), how about just doing: if (bufsize != sizeof (int)) and then you don't need to bother setting bufsize in s10_getattr(). - in s10_elfexec() it seems like the changes required to make ld.so.1 run (ie, "sedp->sed_entry = NULL", "up->u_auxv[i].a_un.a_val =") run should be backported to the sn1 brand. -- usr/src/lib/brand/solaris10/zone/uninstall.ksh - this seems to largely be a duplicate of the unistall script from the pkg(5) gate. i only see two differences between the scripts: - the method used to determine the zfs filesystems for the zone (beadm vs zoneadm) and filtering based on uuids. - the code at the very end under the "Check if there are any other datasets left." comment. this one seems like a potential mismerge, since i would think that you'd actually want to keep this bit of code. to avoid duplicating this entire script, could you please move most this code into usr/lib/brand/shared and either: - make it a common script that is called by a brand specific script that passes it a list of datasets to delete - or have the script take a command line option which controls how the list of datasets to delete is determined. then after you putback the ipkg brand can be updated to use this same code. -- usr/src/lib/brand/solaris10/zone/query.ksh - also a dup of the query in the pkg(5) gate, should be common. -- usr/src/lib/brand/solaris10/zone/s10_boot.ksh - is_zone_dir() looks like a dup of /usr/lib/brand/shared/common.ksh`safe_dir() - shouldn't safe_replace() go into /usr/lib/brand/shared/common.ksh? -- usr/src/lib/brand/solaris10/zone/detach.ksh - do you use anything from? /usr/lib/brand/shared/common.ksh - why? ZONEROOT="$ZONEPATH/root" logdir="$ZONEROOT/var/log" -- usr/src/lib/brand/solaris10/zone/common.ksh - shouldn't the EXIT_* definitions go in /usr/lib/brand/shared/common.ksh? - hm. i find the PROP_ACTIVE and libbe references strange. - there is duplicated code here from the pkg(5) brand common.ksh. perhaps the common code should go in /usr/lib/brand/shared/common.ksh? fail_fatal() get_zonepath_ds() get_active_ds() - in create_active_ds(), newly created datasets will have different values from pre-existing datasets. new datasets will inherit the mountpoint and zoned properties while existing datasets will have these explicitly set. (if your worried about these having incorrect values for existing datasets, perhaps you should re-inherit them instead of setting them.) - in create_active_ds(), you
Re: [zones-discuss] s10 brand Phase I webrev
On Mon, Sep 28, 2009 at 03:06:00PM -0600, Jerry Jelinek wrote: > Edward Pilatowicz wrote: >> hey jerry, >> >> do you have an updated ws+webrev where the s10 files were created using >> hg cp? (i'm waiting for that before doing a review.) >> >> also, when were you planning to integrate? (so i can avoid a last >> minute rush.) > > Ed, > > I wasn't aware that this was holding you up. I haven't > done anything on it yet. I'll work on regenerating the > webrevs by tomorrow and send out an announcement. We > are targeting b127 so it would be good to get any comments > this week so that there is time to respond and test any > changes. > ah. yeah. i was waiting because i wanted to use the hg cp' workspace to generate a webrev using daneks copy of webrev. (since that would show just the delta to all the copied files, there by greatly reducing the amount of code to review.) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
hey jerry, do you have an updated ws+webrev where the s10 files were created using hg cp? (i'm waiting for that before doing a review.) also, when were you planning to integrate? (so i can avoid a last minute rush.) ed On Tue, Sep 15, 2009 at 08:48:19AM -0600, Jerry Jelinek wrote: > We've completed the development for the Phase I > work on the solaris10 brand. I've posted a > full webrev at: > > http://cr.opensolaris.org/~gjelinek/webrev.646/ > > Let me know if there are any comments. > > Thanks, > Jerry > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on shared storage proposal
On Mon, Sep 21, 2009 at 04:25:30PM +0100, John Levon wrote: > On Wed, Sep 16, 2009 at 09:33:11PM -0700, Edward Pilatowicz wrote: > > > there by implying that the vdisk path is a directory. ok. that's easy > > Right. > > > enough to detect. > > It's probably safer to directly use vdiskadm to sniff the directory, if > you can. > sure. > > > At import time, it's a combination of sniffing the type from the file, > > > and some static checks on file name (namely .raw and .iso suffixes). > > > > well, as long as the suffixes above apply to directories and not to > > files then i think we'd be ok. if the extensions above will apply to > > files then we have a problem. > > Once imported, the contents of the vdisk directory are private to vdisk. > The name of the containing directory can be anything. > > That is, an import consists of taking the foo.raw file, and putting it > into a directory along with an XML properties file. > so in this context, an import is one method for creating a vdisk. > > so previously if the user specified: > > file:///.../foo.raw > > then we would create a zpool directly within the file, no label. > > > > and if the user specified: > > vfile:///.../foo.raw > > > > then we would use lofi with the newly proposed -l option to access the > > file, then we'd put a label on it (via the lofi device), and then create > > a zpool in one of the partitions (and once again, zfs would access the > > file through the lofi device). > > > > so in the two cases, how can we make the access mode determination > > without having the seperate uri syntax? > > In the creation case, which I think we're talking about above, we create > the vdisk directory (rather than direct file access, which vdiskadm > can't do, even though vdisk itself can) and the container format is > clear. > > If we want to configure access to a pre-existing raw file, I'm not sure > we'd be doing the labelling ourselves. Perhaps I don't quite understand > the use cases for what you're suggesting. > the two use cases above were creation use cases. i think part of the confusion here is that in the raw case, i thought a vdisk would just have a file, not a directory with an xml file and the disk file. (when i was using xvm that was the format of all the vdisks i created.) the other part of the confusion is that i was trying to support automatic creation for raw vdisks. if we only support vdisks created via vdiskadm(1m), then we'll always have a directory and we can always use vdiskadm(1m) to sniff out if it's a valid vdisk and access it as such. then for the implicit creation case we'll just support files containing a zpool. sound good? > > > How about defaulting to the owner of the containing directory? If it's > > > root, you won't be able to write if you're root-squashed (or not root > > > user) anyway. > > > > > > Failing that, I'd indeed prefer a different user, especially one that's > > > configurable in terms of uid/gid. > > > > if a directory is owned by a non-root user and i want to create a file > > there, i think it's a great idea to switch to the uid of the directory > > owner todo my file operations. i'll add that to the proposal. > > > > but, say i'm on a host that is not subject to root squashing and i need > > to create a file on a share that is only writable by root. in that > > case, should i go ahead and create a file owned by root? imho, no. > > instead, i'd rather create the file as some other user. > > I don't agree that second-guessing the user's intentions when they've > explicitly disabled root-squashing is a useful behaviour. > > > if the administrator then tries to migrate that zone to a host that is > > subject to root squashing from the server, then i'd lose access to that > > file. eliminating all file accesses as root allows us to avoid > > root-squashing and just help eliminate potential failure modes. > > Replacing it with a potentially more subtle issue: what's the zonenfs > user ID, is it configured on the server, and is it unique and reserved > across the organisation, and across all OSes? > > Having access fail with a clear message is an understandable failure > mode, with a clear remedy: use a suitable uid /chosen by the > administrator/. NFS users are surely comfortable and familiar with root > squashing by now. > > Having a MySQL security hole allow access to all your virtual shared > storage is a much more subtle problem (yes, I discovered despite my > initial research that UID 60 is used by some Linux machines as mysqld). > ok. so how about we just generate an error if we need to create a file, and an explicity user id has not been specified, and root squashing is enabled. (because under these conditions we'd generate a file owned by nobody.) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on shared storage proposal
On Thu, Sep 17, 2009 at 01:13:53AM +0100, John Levon wrote: > On Wed, Sep 16, 2009 at 04:34:06PM -0700, Edward Pilatowicz wrote: > > > thanks for taking the time to look at this and sorry for the delay in > > replying. > > Compared to /my/ delay... > > > > That is, I think vdisks should just use path:/// and nfs:// not have > > > their own special schemes. > > > > this is easy enough to change. > > > > but would you mind explaning what is the detection techniques are for > > the different vdisk formats? are they files with well known extensions? > > all directories with well known extensions? directories with certain > > contents? > > Well, the format comes from the XML property file present in the vdisk. there by implying that the vdisk path is a directory. ok. that's easy enough to detect. > At import time, it's a combination of sniffing the type from the file, > and some static checks on file name (namely .raw and .iso suffixes). > well, as long as the suffixes above apply to directories and not to files then i think we'd be ok. if the extensions above will apply to files then we have a problem. in the xvm world, you don't have any issues with accessing the files above since you know that every object exported to a domain contains a virtual disk, and there for contains a label. but with zones this isn't the case. in my proposal there are two access modes for files. raw file mode, where a zpool is created directly inside a file. and vdisk mode, where we first create a label within the device and then create a zpool inside one of the partitions. so previously if the user specified: file:///.../foo.raw then we would create a zpool directly within the file, no label. and if the user specified: vfile:///.../foo.raw then we would use lofi with the newly proposed -l option to access the file, then we'd put a label on it (via the lofi device), and then create a zpool in one of the partitions (and once again, zfs would access the file through the lofi device). so in the two cases, how can we make the access mode determination without having the seperate uri syntax? > > > Hmmph. I really don't want the 'xvm' user to be exposed any more than it > > > is. It was always intended as an internal detail of the Xen least > > > privilege implementation. Encoding it as the official UID to access > > > shared storage seems very problematic to me. Not least, it means xend, > > > qemu-dm, etc. can suddenly write to all the shared storage even if it's > > > nothing to do with Xen. > > > > > > Please make this be a 'user' option that the user can specify (with a > > > default of root or whatever). I'm pretty sure we'd agreed on that last > > > time we talked about this? > > > > i have no objections to adding a 'user' option. > > > > but i'd still like to avoid defaulting to root and being subject to > > root-squashing. > > How about defaulting to the owner of the containing directory? If it's > root, you won't be able to write if you're root-squashed (or not root > user) anyway. > > Failing that, I'd indeed prefer a different user, especially one that's > configurable in terms of uid/gid. > if a directory is owned by a non-root user and i want to create a file there, i think it's a great idea to switch to the uid of the directory owner todo my file operations. i'll add that to the proposal. but, say i'm on a host that is not subject to root squashing and i need to create a file on a share that is only writable by root. in that case, should i go ahead and create a file owned by root? imho, no. instead, i'd rather create the file as some other user. why? because if the administrator then tries to migrate that zone to a host that is subject to root squashing from the server, then i'd lose access to that file. eliminating all file accesses as root allows us to avoid root-squashing and just help eliminate potential failure modes. this would be my argument for adding a new non-root user that could be used as a fallback for remote file access in cases that would otherwise default to the root user. > > there wouldn't really be any problem which changing this from a lofi > > service to be a vdisk service. both services would do the same thing. > > each would have a daemon that keeps track of the current vdisks on the > > system and ensures that a vdisk utility remains running for each one. > > > > if you want smf to manage the vdisk utility processes directly, then > > we'll have to create a new smf service each time a vdisk is accessed > > and destroy that sm
Re: [zones-discuss] zones on shared storage proposal
hey illya, thanks for reviewing this and sorry for the delay in replying. my comments are inline below. i've also attached a document that contains some of the design doc sections i've revised based of your (and john's) feedback. since the document is large, i've only included sections that i've modified, and i've included changebars in the right most column. ed On Mon, Sep 07, 2009 at 11:07:41AM +0300, Illya Kysil wrote: > Hi Edward, > > See comments and questions below inline: > > 1. Section C.0 > > ... That said, nothing in this proposal should not prevent us from adding > > support for... > That "not" before "prevent" is superfluous. > done. > 2. Section C.1.i > How many instances of "rootzpool" and "zpool" resources is permitted? > IMO "zero or one" for "rootzpool" and "zero or more" for "zpool" is enough. > correct. i've updated the proposal to mention this. > 3. Section C.1.iii > > The newly created or imported root zpool will be named after the zone to > > which it is associated, with the assigned name being "_rpool". > What if zone name is changed later? Will the name of the zpool change as well? > It is not clear how the association with the zpool will be maintained > if its name will not change. > the pool name must be kept in sync with the zone name. unfortunatly this presents a problem because currently zone renaming is done from zonecfg and it can be done when a zone is installed, but since zone zpools are imported at install time, we need to disallow re-naming of installed zones. hence, i've added the following new section: C.1.x Zonecfg(1m) misc changes > > This zpool will then be mounted on the zones zonepath and then the > > install process will continue normally[07]. > > > > XXX: use altroot at zpool creation or just manually mount zpool? > What will happen on zoneadm move? IMO the zones framework have to > remount the zpool in the new location. > that's correct. i've added another new section: C.1.ix Zoneadm(1m) move > > If the user has specified a "zpool" resource, then the zones framework > > will configure, initialize, and/or import it in a similar manner to a > > zpool specified by the "rootzpool" resource. The key differences are > > that the name of the newly created or imported zpool will be > > "_". > What if zone name or zpool resource name is changed later? Will the > name of the zpool change as well? > It is not clear how the association with the zpool will be maintained > if its name will not change. > > 4. Section C.1.viii once again, the zpool name will need to be kept in sync with the zonename. > > Since zoneadm(1m) clone will be enhanced to support cloning between > > encapsulated root zones and un-encapsulated root zones, zoneadm(1m) > > clone will be documented as the recommended migration mechanism for > > users who which to migrate existing zones from one format to another. > "users who which" -> "users who wish" > > 5. Section C.5 > > For RAS purposes,... > What is RAS? > a TLA. :) it stand for Reliability, Availability, and Serviceability. > > Here's some examples of how this lofi functionality could be used > > (outside of the zone framework). If there are no lofi devices on > > the system, and an admin runs the following command: > > lofiadm -a -l /export/xvm/vm1.disk > > > > they would end up with the following device: > > /dev/lofi/dsk0/p# - for # == 0 - 4 > > /dev/lofi/dsk0/s# - for # == 0 - 15 > > /dev/rlofi/dsk0/p# - for # == 0 - 4 > > /dev/rlofi/dsk0/s# - for # == 0 - 15 > > > > If there are no lofi devices on the system, and an admin runs the > > following command: > > lofiadm -a -v /export/xvm/vm1.vmdk > > > > they would end up with the following device: > > /dev/lofi/dsk0/p# - for # == 0 - 4 > > /dev/lofi/dsk0/s# - for # == 0 - 15 > > /dev/rlofi/dsk0/p# - for # == 0 - 4 > > /dev/rlofi/dsk0/s# - for # == 0 - 15 > The list of devices is the same in both examples. What's the difference? > the difference is in the invocation, not in the resulte. i've re-worded this section to make things more clear. > 6. Section D > > D. INTERFACES > > > > Zonecfg(1m): > > rootzpool committed, resource > > src committed, resource property > > install-sizecommitted, resource property > What is the meaning of "committed" here? > this is arc terminology. basically, i'm presenting a new user interface here and i'm saying that it isn't going to change incompatibaly in the future. > >Zones misc: > > /var/zones/nfsmount/// > > project private, nfs mount point > The mount point is different from what is described in section C.1.iii > (see additional comment above): oops. fixed. > > If an so-uri points to an explicit nfs server, the z
Re: [zones-discuss] zones on shared storage proposal
thanks for taking the time to look at this and sorry for the delay in replying. my comments are line below. ed On Sat, Sep 05, 2009 at 11:13:07PM +0100, John Levon wrote: > On Thu, May 21, 2009 at 04:55:15PM +0800, Edward Pilatowicz wrote: > > > File storage objects: > > > > path:/// > > nfs://[:port]/ > > > > Vdisk storage objects: > > > > vpath:/// > > vnfs://[:port]/ > > This makes me uncomfortable. The fact it's a vdisk is derivable except > in one case: creation. And when creating, we will already want some way > to specify the underlying format of the vdisk, so we could easily hook > the "make it a vdisk" option there. > > That is, I think vdisks should just use path:/// and nfs:// not have > their own special schemes. > this is easy enough to change. but would you mind explaning what is the detection techniques are for the different vdisk formats? are they files with well known extensions? all directories with well known extensions? directories with certain contents? > > In order to avoid root squashing, or requiring users to setup special > > configurations on their NFS servers, whenever the zone framework > > attempts to create a storage object file or vdisk, it will temporarily > > change it's uid and gid to the "xvm" user and group, and then create the > > file with 0600 access permissions. > > Hmmph. I really don't want the 'xvm' user to be exposed any more than it > is. It was always intended as an internal detail of the Xen least > privilege implementation. Encoding it as the official UID to access > shared storage seems very problematic to me. Not least, it means xend, > qemu-dm, etc. can suddenly write to all the shared storage even if it's > nothing to do with Xen. > > Please make this be a 'user' option that the user can specify (with a > default of root or whatever). I'm pretty sure we'd agreed on that last > time we talked about this? > i have no objections to adding a 'user' option. but i'd still like to avoid defaulting to root and being subject to root-squashing. the xvm user seems like a good way to do this. but if you don't like this then i could always introduce a new user just for this purpose, say the zonesnfs user. > > For RAS purposes, we will need to ensure that this vdisk utility is > > always running. Hence we will introduce a new lofi smf service > > svc:/system/lofi:default, which will start a new /usr/lib/lofi/lofid > > daemon, which will manage the starting, stopping, monitoring, and > > possible re-start of the vdisk utility. Re-starts of vdisk utility > > I'm confused by this bit: isn't startd what manages "starting, stopping, > monitoring, and possible re-start" of daemons? Why isn't this > svc:/system/vdisk:default ? What is lofid actually doing? > well, as specified in the proposal, the administrative interface for accessing vdisks is via lofi: ---8<--- Here's some examples of how this lofi functionality could be used (outside of the zone framework). If there are no lofi devices on the system, and an admin runs the following command: lofiadm -a -l /export/xvm/vm1.disk they would end up with the following device: /dev/lofi/dsk0/p# - for # == 0 - 4 /dev/lofi/dsk0/s# - for # == 0 - 15 /dev/rlofi/dsk0/p# - for # == 0 - 4 /dev/rlofi/dsk0/s# - for # == 0 - 15 ---8<--- so in this case, the lofi service would be started, and it would manage starting and stopping a vdisk utility processes that services the backend for this lofi device. i originally made this a lofi service because i know that eventually it would also be nice if we could persist lofi configuration across reboots, and a lofi smf service would be a good way todo this. there wouldn't really be any problem which changing this from a lofi service to be a vdisk service. both services would do the same thing. each would have a daemon that keeps track of the current vdisks on the system and ensures that a vdisk utility remains running for each one. if you want smf to manage the vdisk utility processes directly, then we'll have to create a new smf service each time a vdisk is accessed and destroy that smf service each time the vdisk is taken down. i don't really have a strong opinion on how this gets managed, so if you have a preference then let me know and i can update the proposal. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
two high level comments to start with. - since the s10 brand is derived from the sn1 brand, are there any framework changes which were made to the s10 brand that should be backported to the sn1 brand? - also, since the s10 brand is derived from the sn1 brand, could you please ensure that all the new s10 brand that are being created are derived from the corresponding sn1 brand files? ie, the s10 brand files which are derived from sn1 brand files should be created via "hg cp ..." instead of "cp ...; hg new ..." (this will preserve the sn1 brand revision history when looking at s10 brand files.) additionally, danek has an enhanced version of webrev where, if the s10 branded files are "hg cp"d from the sn1 files, we'll just see the deltas against the sn1 files (instead of having all these files show up as new). ed On Tue, Sep 15, 2009 at 08:48:19AM -0600, Jerry Jelinek wrote: > We've completed the development for the Phase I > work on the solaris10 brand. I've posted a > full webrev at: > > http://cr.opensolaris.org/~gjelinek/webrev.646/ > > Let me know if there are any comments. > > Thanks, > Jerry > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone installation hangs at " Initializing zone product registry".
On Mon, Sep 14, 2009 at 02:35:07AM -0700, RAjiv Patel wrote: > I have created a zone , namely ems-ora-zoneB. Then to install the zone , I > executed the following command. > > zoneadm -z ems-ora-zoneB install > > It has been more than 40 hours, but the prompt still shows " Initializing > zone product registry". > One more thing is that it also does not show progress of zone installation in > the percentage(%). > > After waiting for 40 hours, I rebooted the machine, and here is what it shows: > > ari23bca# zoneadm list -cv > ID NAME STATUS PATH > 0 global running / > - ems-ora-zoneB configured /opt/ems-ora-zoneB > > > It shows that zone is only "configured" whereas it should have shown that > zone is "installed". > actually, it sounds like the zone install hung, so after rebooting it makes sense that the zone is marked configured and not installed. if you want to get the zone installed you need to figure out why the install is hanging. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] folding brandz into zones on os.o
On Mon, Sep 14, 2009 at 02:02:03PM -0700, Jordan Vaughan wrote: > On 09/14/09 01:55 PM, Edward Pilatowicz wrote: >> hey all, >> >> just a quick heads up. >> >> it's been on my todo list for a very long time (and i figured that i >> really should get it done before the xwiki migration), so i finally >> merged all the brandz community content into the zones community. you >> can see all the moved content here: >> >> http://opensolaris.org/os/community/zones/brandz >> >> The only updates i made to the content in the process of moving it was >> changes to make links self consistent. (ie, so all the brandz >> referencing links in the moved pages now point to the new pages.) >> >> ed >> ___ >> zones-discuss mailing list >> zones-discuss@opensolaris.org > > Cool. It makes more sense to incorporate BrandZ into the zones > community than to separate them into two communities. Is your update > the first step towards killing the BrandZ community? > i just sent email to website-discuss asking when would be the best time to delete the brandz community. before, during, or after the xwiki migration. (i'm guessing that "how" part of the deletion is dependent upon the answer to that question.) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] folding brandz into zones on os.o
hey all, just a quick heads up. it's been on my todo list for a very long time (and i figured that i really should get it done before the xwiki migration), so i finally merged all the brandz community content into the zones community. you can see all the moved content here: http://opensolaris.org/os/community/zones/brandz The only updates i made to the content in the process of moving it was changes to make links self consistent. (ie, so all the brandz referencing links in the moved pages now point to the new pages.) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a new zone using latest OpenSolaris 2009.06
you need three commands: zonecfg(1m) zoneadm(1m) zlogin(1) to configuration a zone, see example 1 in zonecfg(1m). the only required parameter is "zonepath", so in the simplist case (a zone with no networking) just set that. then use zoneadm(1m) to install and boot the zone: zoneadm -z install zoneadm -z boot to get the console of the zone and do login to the zone: zlogin -C zlogin ed On Wed, Sep 09, 2009 at 10:03:39PM -0700, Suraj Sankar wrote: > Hi Kevin/All, > > i am pretty new to open solaris.Could anyone help me with the step by step > installation of zones on open solaris 2009.06. > > Any help will be highly appreciated.. > -- > This message posted from opensolaris.org > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on shared storage proposal
On Sat, Sep 05, 2009 at 09:02:34AM +0300, Illya Kysil wrote: > Hi Edward, > > On Sat, Sep 5, 2009 at 03:03, Edward > Pilatowicz wrote: > > i posted the latest version to our aliases in may after i incorporated > > mike's feedback, but digging throught the archives i couldn't find any > > decent readable copy. hence i've gone ahead and posted the latest > > version to zones community site here: > > > > http://www.opensolaris.org/os/community/zones/zones_design_docs/zoss/ > > I've found readable proposal text attached here - > http://www.opensolaris.org/jive/thread.jspa?threadID=103319&tstart=0 seems i'm forum searching foo isn't all that good. > It is titled "Zones on shared storage (v1.1)" rather than "Zones on > shared storage, v0.9" > which you posted. It looks like it is the most recent version anybody has. :) > oops. so first off, sorry about posting an older version. that said, since i wrote the doc i do really have the latest version. ;) i've posted v1.2 (which incorporates mikes feedback) at the url above. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on shared storage proposal
hey illya, i posted the latest version to our aliases in may after i incorporated mike's feedback, but digging throught the archives i couldn't find any decent readable copy. hence i've gone ahead and posted the latest version to zones community site here: http://www.opensolaris.org/os/community/zones/zones_design_docs/zoss/ fyi, the work described in the document is currently unfunded (ie, no one is actually working on it), but if you have comments/feedback on the design then please let me know and i can try to address it. ed On Sat, Sep 05, 2009 at 01:37:19AM +0300, Illya Kysil wrote: > Hello Edward and Mike, > > I've just discovered your thread from May 2009. > Do you have any updates on the subject? > I would like to read the latest version of the proposal. > Where can I find it? > > -- > Illya Kysil > -- > "EASY" is the word you use to describe other people's job. > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] sysidcfg - root password
no, it likely wouldn't be the same. the classic unix crypt uses a
"salt" to allow for different encodings of the same text string. see:
http://en.wikipedia.org/wiki/Crypt_(Unix)
ed
On Wed, Aug 26, 2009 at 03:00:01PM -0400, Mike Wahlberg wrote:
> Also I created a root passwd on my Solaris 10 U7
> box as abc123, and the encryption from my /etc/shadow
> is MNY4FaPMbBnRs, not what you supplied. I would
> think the encryption would be the same.
>
> Mike
>
>
> Edward Pilatowicz wrote:
>> are you running opensolaris?
>>
>> if so, i'm guessing that the problem is the format of the hashed
>> password. by default, solaris version <= 10 and nevada use crypt for
>> hashing passwords, but opensolaris uses SHA256. these settings seem to
>> be controlled via /etc/security/policy.conf. just search for string
>> CRYPT_* in that file and read the associated comments.
>>
>> ed
>>
>> On Wed, Aug 26, 2009 at 08:35:19AM -0700, v wrote:
>>
>>> Hello,
>>>
>>> I use sysidcfg to configure my zone. However, during configuration, the
>>> root password gives a syntax error. The password I use in the sysidcfg is
>>> the encrypted version of abc123. I don't know why it doesn't like it. Let
>>> me walk you through my zone creation process. Maybe somebody can tell me
>>> what I am doing wrong... (By the way, this is an exclusive IP zone)
>>>
>>> 1) Install the zone
>>> 2) Make the zone ready (zoneadm -z zone1 ready)
>>> 3) Copy the below sysidcfg to the root/etc/ directory
>>>
>>> terminal=vt100
>>> network_interface=primary { dhcp protocol_ipv6=yes }
>>> name_service=DNS nfs4_domain=dynamic
>>> security_policy=none
>>> timezone=US/Eastern
>>> system_locale=C
>>> root_password=fto/dU8MKwQR
>>>
>>> 4) Login to the zone (zlogin -C zone1)
>>> 5) Open another connection to the global zone
>>> 6) Boot zone1 (zoneadm -z zone1 boot)
>>> 7) Then, I see the configuration process on the other terminal screen as
>>> outlined below. It stops at the root password line and switches over to
>>> the interactive configuration
>>>
>>> [NOTICE: Zone booting up]
>>>
>>> SunOS Release 5.11 Version snv_111b 32-bit
>>> Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved.
>>> Use is subject to license terms.
>>> Hostname: zone1
>>> Reading ZFS config: done.
>>> Mounting ZFS filesystems: (6/6)
>>> root_password=fto/dU8MKwQR
>>> syntax error line 8 position 15
>>> Creating new rsa public/private host key pair
>>> Creating new dsa public/private host key pair
>>> Configuring network interface addresses: vnic1
>>> --
>>> This message posted from opensolaris.org
>>> ___
>>> zones-discuss mailing list
>>> zones-discuss@opensolaris.org
>>>
>> ___
>> zones-discuss mailing list
>> zones-discuss@opensolaris.org
>>
>
>
> --
> Michael Wahlberg
> OS Collaborator
> Sun Technology Center
> Sun Microsystems, Inc.
> 75 Network Drive
> Burlington, Mass. 01803 Phone: 781-442-1332 Email
> michael.wahlb...@sun.com
> Hours: Monday-Friday 7:30am-4PM EST
> Manager: joel.fonte...@sun.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] sysidcfg - root password
are you running opensolaris?
if so, i'm guessing that the problem is the format of the hashed
password. by default, solaris version <= 10 and nevada use crypt for
hashing passwords, but opensolaris uses SHA256. these settings seem to
be controlled via /etc/security/policy.conf. just search for string
CRYPT_* in that file and read the associated comments.
ed
On Wed, Aug 26, 2009 at 08:35:19AM -0700, v wrote:
> Hello,
>
> I use sysidcfg to configure my zone. However, during configuration, the root
> password gives a syntax error. The password I use in the sysidcfg is the
> encrypted version of abc123. I don't know why it doesn't like it. Let me
> walk you through my zone creation process. Maybe somebody can tell me what I
> am doing wrong... (By the way, this is an exclusive IP zone)
>
> 1) Install the zone
> 2) Make the zone ready (zoneadm -z zone1 ready)
> 3) Copy the below sysidcfg to the root/etc/ directory
>
> terminal=vt100
> network_interface=primary { dhcp protocol_ipv6=yes }
> name_service=DNS
> nfs4_domain=dynamic
> security_policy=none
> timezone=US/Eastern
> system_locale=C
> root_password=fto/dU8MKwQR
>
> 4) Login to the zone (zlogin -C zone1)
> 5) Open another connection to the global zone
> 6) Boot zone1 (zoneadm -z zone1 boot)
> 7) Then, I see the configuration process on the other terminal screen as
> outlined below. It stops at the root password line and switches over to the
> interactive configuration
>
> [NOTICE: Zone booting up]
>
> SunOS Release 5.11 Version snv_111b 32-bit
> Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved.
> Use is subject to license terms.
> Hostname: zone1
> Reading ZFS config: done.
> Mounting ZFS filesystems: (6/6)
> root_password=fto/dU8MKwQR
> syntax error line 8 position 15
> Creating new rsa public/private host key pair
> Creating new dsa public/private host key pair
> Configuring network interface addresses: vnic1
> --
> This message posted from opensolaris.org
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zpools in zones
On Wed, Jul 15, 2009 at 11:28:21AM -0700, Alastair Neil wrote: > I am trying to set up two zones to exactly duplicate a production server one > for test and one for development. The production server has a number of > zpools which are specifically named and the scripts we are testing expect > this naming. > > I have run in to a brick wall, as it seems that it is impossible to create > zpools inside a zone, I can add devices ( zfs volumes) from the global zone > or add files systems but since I need two distinct but identical environments > I am at a loss how to proceed. > > Any pointers? it's not possible to create or manage zpools inside of zones. the best you can do is create a zpool in the global zone, and then use the zonecfg dataset resource to dedicate that zpool dataset to a zone. then you can create and manage zfs datasets within that zpool using the zfs command. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Preconfiguring ipkg Brand Zones
On Tue, Jul 07, 2009 at 10:41:36AM -0700, Brian Leonard wrote: > I've been struggling to use the sysidcfg file to preconfigure my zones in > 2009.06. I've read a couple of other posts where folks have also struggled > (http://opensolaris.org/jive/thread.jspa?messageID=307290, > http://opensolaris.org/jive/thread.jspa?messageID=319155). Before filing an > issue I wanted to run it by this alias to see if I'm missing something. Here > are the steps I'm using: > > cat myzone.config > create -b > set zonepath=/zones/myzone > set brand=ipkg > set autoboot=false > set ip-type=shared > add net > set address=10.0.1.25 > set physical=e1000g0 > end > > pfexec zonecfg -z myzone < myzone.config > > pfexec zoneadm -z myzone install > > At this point, there is no etc directory, so I create one: > > pfexec mkdir /zones/myzone/root/etc > and this is where things go off the rails... you can't just create this directory since when the zone get's booted the zone root filesystem will be mounted here and whatever you've created will get covered up. i'm not sure what the best workaround is. one thing you might try is changing the zone to the "ready" state before creating your sysidcfg file. ie, do: zoneadm -z myzone ready then create the sysidcfg file and boot the zone as your normally would. let us know if that works... ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review request: SUNWzoneint removal
On Wed, Jun 17, 2009 at 02:52:17PM -0400, James Carlson wrote:
> Edward Pilatowicz writes:
> > > W3 says that we shouldn't (at least) ship compilation symlinks for
> > > private libraries.
> > >
> >
> > sure, it says that. and then the first NOTE says you can ship them to
> > simplify compilation. i thought about removing these links, but then i
> > looked at libzfs and libdtrace as my examples and those seem to have the
> > "convience" compilation links as well.
>
> Not sure if you need usr/src/tools/abi/etc/exceptions entries in that
> case. Do you?
>
a fine question. as best as i can tell, no. the previously mentioned
example libraries (dtrace and zfs) don't have entries here. Also, i've
done a full nightly on both sparc and x86 with the -A flag enabled
(which runs intf_check, which seems to be the only consumer of the file
above) and that hasn't generated any errors. then just to be extra sure
i did a full sparc/x86 nightly without my changes and compared the
output from intf_check to make sure it isn't changing.
> > IPS is a development project that is targeting the ON gate, but due to
> > artifacts of the current development process, it is not currently based
> > on the ON gate. hence i don't think that IPS needs a contract to access
> > ON Consolidation Private interfaces.
>
> OK.
>
> > i don't know where Caiman plans to integrate. i would guess ON (since
> > the install gate is going away), but perhaps due to nostalgia we'll get
> > a new install gate? ;)
>
> ;-}
>
> In that case, my comments are just:
>
> - The CR is stuck in Dispatched ("nobody cares") state. It needs to
> be at least "Fix Understood" with an Evaluation included.
>
i'll update this.
> - The ABI exceptions entry isn't present ... but I have no idea what
> state the ABI tools are actually in.
>
hm. looking further at the exceptions file, i don't think it's looking
for links to libraries with only private interfaces. it seems to be
more concerned with detecting interface versioning errors introduced by
changes in scope or version number of exisiting interfaces.
i don't really thing there's anything that needs to be done here for my
changes.
thanks
ed
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] code review request: SUNWzoneint removal
On Wed, Jun 17, 2009 at 08:23:43AM -0400, James Carlson wrote: > Edward Pilatowicz writes: > > http://cr.opensolaris.org/~edp/onnv-headers1/ > > 6851400 SUNWzoneint files should be moved to SUNWzoneu > > > > i'm eliminating the SUNWzoneint package because there really is no good > > reason not to ship these header files and lint libraries. > > They weren't shipped because the libraries are Consolidation Private. > Per the library best practices document: > > http://sac.sfbay/cgi-bin/bp.cgi?NAME=Libraries.bp > > W3 says that we shouldn't (at least) ship compilation symlinks for > private libraries. > sure, it says that. and then the first NOTE says you can ship them to simplify compilation. i thought about removing these links, but then i looked at libzfs and libdtrace as my examples and those seem to have the "convience" compilation links as well. that said, personally i don't really care if they are present or not as long as things continue to compile. if you'd like i could try removing them and seeing how builds go. > Because they are contracted for use outside of ON, they were put into > SUNWzoneint for build machines. I agree that it's annoying at best, > but it is part of the current "best practices." > i know why they weren't shipped. but we already ship lots of libraries + lint libraries + headers files for stuff that only contains private interfaces. also, W3 does have plenty of NOTEs which document cases where shipping these things is appropriate. i believe that in this case shipping this stuff is appropriate. > > they are > > already needed for building the caiman gate, and i want to use them for > > functionality in the ips gate as well. > > So ... are these libraries now some form of Public interface? Or will > IPS and Caiman have contracts, and is this just an exception to the > usual rules? > IPS is a development project that is targeting the ON gate, but due to artifacts of the current development process, it is not currently based on the ON gate. hence i don't think that IPS needs a contract to access ON Consolidation Private interfaces. i don't know where Caiman plans to integrate. i would guess ON (since the install gate is going away), but perhaps due to nostalgia we'll get a new install gate? ;) ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] code review request: SUNWzoneint removal
hey all, i need a code review for: http://cr.opensolaris.org/~edp/onnv-headers1/ 6851400 SUNWzoneint files should be moved to SUNWzoneu i'm eliminating the SUNWzoneint package because there really is no good reason not to ship these header files and lint libraries. they are already needed for building the caiman gate, and i want to use them for functionality in the ips gate as well. thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] 2 line code review...
On Mon, Jun 15, 2009 at 03:46:29PM -0700, Dan Price wrote: > 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? > yep. the native brand on SXCE does not supply any verify callbacks: ---8<--- e...@jurassic-x4600$ grep verify /usr/lib/brand/native/config.xml ---8<--- thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] 2 line code review...
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 thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand code review
On Mon, Jun 15, 2009 at 11:54:46AM -0600, Jerry Jelinek wrote: > Ed, > > Thanks for reviewing this. > > Edward Pilatowicz wrote: >> - you might want to add the crypto libraries to the list of libraries >> to watch for breakage. ;) > > Yep. :-) I'm also going to try to see if any of the other default devices > that are inside of a zone might have had their ioctl params changes > in any way. > >> - to improve the readability of crypto_ioctl(), could you make a >> dedicated function or macro that just does translation between >> the s10 and nevada versions of crypto_get_function_list_t? > > Will do. > >> - when you make the ioctl call, i see you can do a CT_TSET. in >> this scenario you only initialize native_param.fl_provider_id, >> and the rest of native_param is garbage. is that ok or should >> the rest of native_param be zeroed out? > > For CT_TSET that goes through the new ctfs_ioctl() function, > not this new code for /dev/crypto. That function is the original > code Jordan did which I just moved out into its own function > for readability. > oops. my bad. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand code review
- you might want to add the crypto libraries to the list of libraries to watch for breakage. ;) - to improve the readability of crypto_ioctl(), could you make a dedicated function or macro that just does translation between the s10 and nevada versions of crypto_get_function_list_t? - when you make the ioctl call, i see you can do a CT_TSET. in this scenario you only initialize native_param.fl_provider_id, and the rest of native_param is garbage. is that ok or should the rest of native_param be zeroed out? ed On Mon, Jun 15, 2009 at 10:39:39AM -0600, Jerry Jelinek wrote: > I need a code review for the fix for: > > ssh dumping core on maramba > > There is a webrev at: > > http://cr.opensolaris.org/~gjelinek/webrev.crypto/ > > Thanks, > Jerry > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
