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 edward.pilatow...@oracle.com 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] 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] 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
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
[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] 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] 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: policy[:pkg-group] The pkg-group 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 policy 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
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 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] 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] 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] 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=123301tstart=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] 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 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 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 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] 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 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] 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] 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] 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 dont 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] 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 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] 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] 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] 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] 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 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] 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: snip end # 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 snip end 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] 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] 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] 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 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 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] 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 zone 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 * 21 | grep brand pkg://development/SUNWipkg-brand init...@dogpatch:~# pkg info -r * 21 | 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 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() and during inital mount processing by observing the NFS4ERR_MOVED error and it'll fetch the new location information from the server via the 'fs_locations' attribute. Our client will then go off and automatically mount the file system from the different server it had been referred to from the inital server. Again like mirror mounts, this is done transparently for the user and inside the kernel. The minor but important quirk involved here as far as our observation from the Zone NFS client is concered is that we might get for our mount attempt (or access to) server_A:/vol/zones1 a mount established instead for server_B:/vol
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://host[:port]/file-absolute'. 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] 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] 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
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] 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] 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] 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 dataset_mounted_on_/zone1 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] 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
[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] 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
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] 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 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
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 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
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 cpd 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_auditsys(), wouldn't it make sense to reduce the indentation by doing: if (bsmcmd != BSM_AUDITCTL) return (__systemcall(rval, SYS_auditsys + 1024, bsmcmd, a0, a1, a2)); - the comment above s10_exec_native() says
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 cpd 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 should check the return value for mkdir. - in sysunconfig_zone(), the comment says it sleeps 10 seconds, but then it does 10 iterations of a loop with sleep 10 in it. i feel like i've made this exact same code review comment to you recently. is this code duplicated from the ipkg p2v code
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] 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] 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 cpd 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] 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:///file-absolute nfs://host[:port]/file-absolute Vdisk storage objects: vpath:///file-absolute vnfs://host[:port]/file-absolute 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] 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 zonename_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 zonename_name. 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/zonename/host/nfs-share-name 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 zones framework will need to mount the nfs filesystem containing storage object. The nfs server share containing
[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] 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] 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 zonename install zoneadm -z zonename boot to get the console of the zone and do login to the zone: zlogin -C zonename zlogin zonename 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
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
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
[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
[zones-discuss] Fwd: Re: snv domU + zones ?
this is just a heads up about: 6738714 guest domains should be able to use multiple unicast addresses this bug prevents zones from using vnics when inside of domUs. (it's an old bug but it just came to my attention, so i figured it might be news to others as well.) ed - Forwarded message from David Edmondson d...@sun.com - Date: Mon, 15 Jun 2009 16:21:20 +0100 From: David Edmondson d...@sun.com To: Edward Pilatowicz edward.pilatow...@sun.com Cc: Fajar A. Nugraha fa...@fajar.net, xen-disc...@opensolaris.org Subject: Re: snv domU + zones ? * edward.pilatow...@sun.com [2009-06-11 19:22:18] On Thu, Jun 11, 2009 at 03:35:52PM +0100, David Edmondson wrote: * fa...@fajar.net [2009-06-11 15:10:34] On Thu, Jun 11, 2009 at 2:58 PM, David Edmondsond...@sun.com wrote: VNICs inside a domU don't work very well (in fact, they work fine, they just don't get to see any traffic from outside the domU) Why is that? I had thought it would be somewhat similar to tun/tap + bridge in Linux, where you can have tun/tap interfaces and bridges in dom0, domU, or both, and they'd function correctly as expected. It's not similar to Linux in this respect. The VNIC implementation would be better described as a non-learning switch (e.g. you assign ports to VMs and each port has an assigned MAC address). There's an RFE to fix this (allow the guest to add more unicast MAC addresses), but it's not yet completed. what's the CR number for this RFE? 6738714 dme. -- David Edmondson, Sun Microsystems, http://dme.org - End forwarded message - ___ 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
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
[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] 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 verify_cfg/verify_cfg verify_adm/verify_adm ---8--- thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Newbie: Just upgraded from 2008.11 to 2009.06 and zone
On Sat, Jun 13, 2009 at 02:25:16PM -0700, Ian wrote: this error seems to indicate that the zone state in /etc/zones/index is invalid. (normally people shouldn't edit this file for exactly this reason. ;) what are the contents of this file? I've attached the full file to this post, but the line for the zone I'm trying right now reads: web:uninstalled:/space/zones/web:1707fafd-4a25-69f6-91e4-92af2073dca4 Is there somewhere that the UUID gets generated from that I can check for consistency ? the UID is not your problem. the problem is that uninstalled is not a valid zone state. (sorry, i just checked my sent emails and i did indeed tell you to set the state to uninstalled, my bad.) the proper state is configured. you need to specify a zfs dataset name, not a filesystem path. on my laptop i would specifly something like: -d rpool/export/zones/z2/ROOT/zbe Aha - thanks. That was the second one I tried, just for the record: # zoneadm -z web attach -u -d space/zones/web/ROOT/zbe zoneadm: web: could not get state: No such zone configured Thanks, -- Ian. -- 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] Newbie: Just upgraded from 2008.11 to 2009.06 and zones fail to boot
hm. detach is failing because attach never marked any zone dataset as active. could you file a bug against detach to make it more robust in the face of failiures? to work around this problem you might just want to edit /etc/zones/index and change the zone state to uninstalled. (this will essentially undo the attach -F you did earlier.) then you can do an attach -u to properly attach the zone. ed On Fri, Jun 12, 2009 at 09:12:53AM -0700, Ian wrote: Hi Jerry, Ok - I fell through the cracks on the upgrade: nothing new there ! I am having some trouble with the detaching though: # zoneadm -z web detach ERROR: Error: no active dataset. Do I have to mount/unmount web/ROOT/zbe manually before trying this ? I think I tried most combinations of zfs mount/unmount last night when I ran into this, but haven't managed to solve it :( Thanks, -- Ian. -- 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] Newbie: Just upgraded from 2008.11 to 2009.06 and zone
On Fri, Jun 12, 2009 at 01:50:16PM -0700, Ian wrote: once you've changed the state to uninstalled, you don't need to do a detach. just do: zoneadm -z lt;zonegt; attach -u -d lt;zbe_datasetgt; Unfortunately, it doesn't like that either: # zoneadm -z web attach -u -d /space/zones/web/ROOT/zbe zoneadm: web: could not get state: No such zone configured this error seems to indicate that the zone state in /etc/zones/index is invalid. (normally people shouldn't edit this file for exactly this reason. ;) what are the contents of this file? I tried a selection of paths and ZFS pool names, just in case. Same result. you need to specify a zfs dataset name, not a filesystem path. on my laptop i would specifly something like: -d rpool/export/zones/z2/ROOT/zbe ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can you plese let me know whether OpenSolaris 2009.6 support sparse zonnes?
On Fri, Jun 05, 2009 at 09:39:12AM +0200, Nicolas Dorfsman wrote: Le 5 juin 09 à 04:45, Edward Pilatowicz a écrit : The difference between Solaris 10 and OpenSolaris is that, on Solaris 10 by using the create would automatically inherit all the 4 directories mentioned above, and by using create -b would create a whole-root zone. On OpenSolaris, however, by using create (without the -b option) would be creating whole-root zones as it does not inherit any directories from the global zones. It would be nice also if you could explain what is the rationale behind this difference. Thanks! the reason for the difference is that SRV4 packaging is very different from ipkg. Solaris 10 is based of SRV4 packaging and opensolaris is based off of ipkg. ipkg will enable us to do lots of things we couldn't with SRV4 packaging. one of the things we will be able to do is have different contents installed in the global zone and non-global zones. hence inherit-pkg-dir doesn't make a whole lot of sense in this context. ipkg seems to be a great advanced techno. Anyway, it's incredible to remove the inherit-pkg facility. no one removed inherit-pkg-dir. inherit-pkg-dir is closely tied to svr4 packaging, and it still works for systems that use svr4 packaging. but opensoalris uses ipkg, and ipkg replaces svr4. so if we want inherit-pkg-dir support we'd need to re-implement it for ipkg. that is work that hasn't been done yet. inherit-pkg-dir has a lot of sense in many users context ! yes, we (the zones development team, of which i am a member) are well aware of that. I really can't understand how somebody could have validated this : hey ipkg great thing, sparse-zone bad thing...let's remove this. that never happened. Where is the team who create the zone concept here ? you're talking to them on this forum. Where is the thread I missed where this great feature suppression was discussed ? Is there only developpers on board ? calm down. take a deep breath. there is no feature suppression going on. ipkg is changing a lot of things. ipkg zones currently don't support all the functionality that svr4 zones do. there's still a lot of work here to be done. wrt inherit-pkg-dir, we (the zones team) are aware that it provides certain indirect features that users like. for example: - keeping zone software contents in sync with the global zone - read only filesystem (an artifact of using lofi) - etc. as we work on improving the ipkg brand we will be looking at these types of features (previously provided by the inherit-pkg-dir option) and evaluating how they should best be implemented in the ipkg brand. (either via the inherit-pkg-dir option as everyone currently knows it, or perhaps via multiple new options that can be used to replace the old inherit-pkg-dir.) if you'd like to participate in this development process then you've come to the right place. thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Creating a new zone using latest OpenSolaris 2009.06
hey kevin, this is a known issue that is being fixed. (i thought the fix had already been pushed to the public repo, but i guess it hasn't happened yet.) there is a pretty straitforward workaround. do a pkg image-update, boot to the new image, and then your zone install should work. ed On Thu, Jun 04, 2009 at 06:21:39PM -0700, Kevin Pan wrote: Hi, I have installed the latest OpenSolaris 2009.06 and tried to create a new zone. I have tried both installations on my local machine as well as launching a OpenSolaris 2009.06 instance on Amazon EC2. Both came up with something like this: --- ad...@computer:/zones# zoneadm -z testspeed install A ZFS file system has been created for this zone. Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/). Image: Preparing at /zones/testspeed/root. Sanity Check: Looking for 'entire' incorporation. ERROR: Unable to locate the incorporation 'ent...@0.5.11,5.11-0.111:20090514T145840Z' in the preferred publisher 'opensolaris.org'. Use -P to supply a publisher which contains this package. ad...@computer:/zones# --- Does anyone has any idea why? How can I resolve this problem? Thanks! Kevin. -- 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] Can you plese let me know whether OpenSolaris 2009.6 support sparse zonnes?
On Thu, Jun 04, 2009 at 07:07:36PM -0700, Kevin Pan wrote: I don't understand your statement that OpenSolaris 2009.06 does not support sparse zone. I would appreciate if you could clarify what you meant by We don't have sparse zones in 2009.06... I thought by using the commands add inherit-pkg-dir, set dir=/xxx (for /lib, /platform, /sbin and /usr) would create so-called sparse-zones on OpenSolaris 2009.06. In fact, I have just successfully doen this a few mintues ago. um. don't do that. the inherit-pkg-dir property is only applicable to solaris distros which use SVR4 packaging. (this means solaris 10 and SXCE). it is not applicable to opensolaris system. using it on opensolaris based systems will result in undefined behaviors and unsupporable configurations. we actually have a bug filed on this issue: 567 ipkg zones verify callback should abort if it sees inherit-pkg-dir http://defect.opensolaris.org/bz/show_bug.cgi?id=8567 the fix for this bug will verify that ipkg brand zone configurations don't have any inherit-pkg-dir properties, and if they do the configuration will be reported as invalid. The difference between Solaris 10 and OpenSolaris is that, on Solaris 10 by using the create would automatically inherit all the 4 directories mentioned above, and by using create -b would create a whole-root zone. On OpenSolaris, however, by using create (without the -b option) would be creating whole-root zones as it does not inherit any directories from the global zones. It would be nice also if you could explain what is the rationale behind this difference. Thanks! the reason for the difference is that SRV4 packaging is very different from ipkg. Solaris 10 is based of SRV4 packaging and opensolaris is based off of ipkg. ipkg will enable us to do lots of things we couldn't with SRV4 packaging. one of the things we will be able to do is have different contents installed in the global zone and non-global zones. hence inherit-pkg-dir doesn't make a whole lot of sense in this context. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones on shared storage proposal
hey mike, thanks for all the great feedback. my replies to your individual comments are inline below. i've updated my proposal to include your feedback, but i'm unable to attach it to this reply because of mail size restrictions imposed by this alias. i'll send some follow up emails which include the revised proposal. thanks again, ed On Thu, May 21, 2009 at 11:59:22AM -0500, Mike Gerdts wrote: On Thu, May 21, 2009 at 3:55 AM, Edward Pilatowicz edward.pilatow...@sun.com wrote: hey all, i've created a proposal for my vision of how zones hosted on shared storage should work. if anyone is interested in this functionality then please give my proposal a read and let me know what you think. (fyi, i'm leaving on vacation next week so if i don't reply to comments right away please don't take offence, i'll get to it when i get back. ;) ed I'm very happy to see this. Comments appear below. please ensure that the vim modeline option is not disabled vim:textwidth=72 --- Zones on shared storage (v1.0) [snip] -- C.1.i Zonecfg(1m) The zonecfg(1m) command will be enhanced with the following two new resources and associated properties: rootzpool resource src resource property install-sizeresource property zpool-preserve resource property dataset resource property zpool resource src resource property install-sizeresource property zpool-preserve resource property nameresource property The new resource and properties will be defined as follows: rootzpool - Description: Identifies a shared storage object (and it's associated parameters) which will be used to contain the root zfs filesystem for a zone. zpool - Description: Identifies a shared storage object (and it's associated parameters) which will be made available to the zone as a delegated zfs dataset. That is to say put your OS stuff in rootzpool, put everything else in zpool - right? yes. as i see it, this proposal allows for multiple types of deployment configurations. - a zone with a single encapsulated rootzpool zpool. the OS will reside in zonename_rpool/ROOT/zbeXXX everything else will also reside in zonename_rpool/ROOT/zbeXXX - a zone with a single encapsulated rootzpool zpool. the OS will reside in zonename_rpool/ROOT/zbeXXX everything else will reside in zonename_rpool/dataset/dataset - a zone with multiple encapsulated zpools. the OS will reside in zonename_rpool/ROOT/zbeXXX everything else will reside in other encapsulated zpools i've added some text to this section of the proposal to explain these different configuration scenarios. -- C.1.ii Storage object uri (so-uri) format The storage object uri (so-uri) syntax[03] will conform to the standard uri format defined in RFC 3986 [04]. The nfs URI scheme is defined in RFC 2224 [05]. The so-uri syntax can be summarised as follows: File storage objects: path:///file-absolute nfs://host[:port]/file-absolute Vdisk storage objects: vpath:///file-absolute vnfs://host[:port]/file-absolute Device storage objects: fc:///wwn[@lun] iscsi:///alias=alias[@lun] iscsi:///target=target[@lun] iscsi://host[:port]/[tpgt=tpgt/]target=target[@lun] File storage objects point to plain files on a local, nfs, or cifs filesystems. These files are used to contain zpools which store zone datasets. These are the simplest types of storage objects. Once created, they have a fixed size, can't be grown, and don't support advanced features like snapshotting, etc. Some example file so-uri's are: path:///export/xvm/vm1.disk - a local file path:///net/heaped.sfbay/export/xvm/1.disk - a nfs file accessible via autofs nfs://heaped.sfbay/export/xvm/1.disk - same file specified directly via a nfs so-uri Vdisk storage objects are similar to file storage objects in that they can live on local, nfs, or cifs filesystems, but they each have their own special data format and varying featuresets, with support for things like snapshotting, etc.. Some common vdisk formats are: VDI, VMDK and VHD. Some example vdisk so-uri's are: vpath:///export/xvm/vm1.vmdk - a local vdisk image vpath:///net/heaped.sfbay/export/xvm/1.vmdk - a nfs vdisk image accessible via autofs vnfs://heaped.sfbay/export/xvm/1.vmdk - same vdisk image specified directly via a nfs so-uri Device storage objects
Re: [zones-discuss] zones on shared storage proposal
[ third reply, includes revised proposal + change bars from previous version ] hey mike, thanks for all the great feedback. my replies to your individual comments are inline below. i've updated my proposal to include your feedback, but i'm unable to attach it to this reply because of mail size restrictions imposed by this alias. i'll send some follow up emails which include the revised proposal. thanks again, ed please ensure that the vim modeline option is not disabled vim:textwidth=72 --- Zones on shared storage (v1.1) | -- A. INTRODUCTION The most commonly requested zones feature is support for the NFS server within a zone (4964859). The next two most requested zones features are support for hosting zones on shared storage, specifically NFS and iSCSI. These last two requests are being tracked via the following bugs: 6688400 Want zonepath on iscsi targets 4963321 RFE: hosting root filesystems for Zones on NFS servers This document proposed a plan to address the latter two issues. These proposed changes will also start to bring the zones storage administration closer in line with the experience provided by other virtualization technologies (VTs, examples of which are xVM, LDOMs, and VirtualBox). -- B. BACKGROUND Currently, it is possible to combine existing supported technologies (FC, iSCSI, NFS, lofi, zfs, etc) to host zones on shared storage, and there are a few blog entries out there describing how to create such configurations[00]. While these configurations are usable and technically supportable, they require extensive configuration of multiple different technologies, making them complex, potentially fragile (since they are not regularly tested), and out of reach for most customers. Creating these configurations today also causes problems with the use of other existing zones features, the most obvious of which is zone migration. These configurations complicate zone migration because all of the additional global zone configuration that was required to host the zone on shared storage must be tracked and then migrated along with the zone data itself. VM Migration is critical component of all existing VTs and anything that can be done to improve zone migration support would be a great benifit to zones administrators. All the other virtualization technologies currently available in Solaris support the hosting of Virtual Machines (VMs) on shared storage. They all do this in the same fashion, which involves taking a storage object[01] which is accessible from the global zone[02], and making it visible within the VM as a local disk. In this document we're refer to this process as encapsulation, since the disk which a VM thinks it's accessing is actually contained (ie encapsulated) within some storage object in the global zone. This encapsulation has advantages and disadvantages. Encapsulation makes it easier to manage the storage associated with VMs. These storage objects may be accessible from multiple hosts simultaneously. They can be backed up, restored, moved around, and copied as individual files instead of filesystems. One disadvantage of the encapsulation used by these other VTs is that currently on Solaris, there is no way to open up these encapsulated disks and access their contents from the global zone. Currently, the only way to access these encapsulated disks is to import them into a running VM. Another interesting development with these encapsulated disks used by other VTs is the proliferation of storage object formats. These custom storage objects formats allows for features which are transparent to the VM using the disks and independent of any features offered by the underlying global zone. While specific feature sets may vary, common features that may be supported are things like compression, sparseness, dedup, snapshotting, and rollback. Management of all these storage object features is usually done from the global zone. Examples of some of these different formats are: VDI - VirtualBox Virtual HDD VHD - Microsoft Virtual Hard Disk VMDK - VMWare Virtual Machine Disk These formats are also commonly used for moving and sharing VM images, and it's not uncommon for users to take VMs encapsulated in one format and convert them into another. -- C. PROPOSAL / DESCRIPTION The essence of this proposal is to enhance zonecfg(1m) to allow for the specification of shared storage objects which can be used to encapsulate zone filesystems, including the zones root filesystem. Once shared storage objects are specified in zonecfg(1m) the management of this shared storage will be handled automatically by the zones framework. This will allow administrators to host zones on shared storage with no additional system configuration being required outside of zonecfg(1m). It will also
Re: [zones-discuss] zones on shared storage proposal
comments inline below. ed On Fri, May 22, 2009 at 11:26:06AM -0500, Mike Gerdts wrote: On Fri, May 22, 2009 at 1:57 AM, Edward Pilatowicz edward.pilatow...@sun.com wrote: i've attached an updated version of the proposal (v1.1) which addresses your feedback. (i've also attached a second copy of the new proposal that includes change bars, in case you want to review the updates.) As I was reading through it again, I fixed a few picky things (mostly spelling) that don't change the meaning. I don't think that I fixed anything that was already right in British English. diff attached. i've merged your fixes in. thanks. On Thu, May 21, 2009 at 11:59:22AM -0500, Mike Gerdts wrote: On Thu, May 21, 2009 at 3:55 AM, Edward Pilatowicz edward.pilatow...@sun.com wrote: nice catch. in early versions of my proposal, the nfs:// uri i was planning to support allowed for the specification of mount options. this required allowing for per-zone nfs mounts with potentially different mount options. since then i've simplified things (realizing that most people really don't need or want to specify mount options) and i've switched to using the the nfs uri defined in rfc 2224. this means we can do away with the 'zonename' path component as you suggest. That was actually something I thought about after the fact. When I've been involved in performance problems in the past, being able to tune mount options (e.g. protocol versions, block sizes, caching behavior, etc.) has been important. yeah. so the idea is to keep is simple for the initial functionality. i figure that i'll evaluate different options and provide the best defaults possible. if customer requests come in for supporting different options, well, first they can easily work around the issue by using autofs + path:/// (and if the autofs config is in nis/ldap, then migration will still work). then we can just come up with a new uri spec that allows the user to specify mount options. the non-obvious and unfortunate part of having a uri that allows for the specification of mount options is that this we'll probably have to require that the user percent-encode certain chars in the uri. :( leaving this off for now gives me a simpler nfs uri format. (that should be good enough for most people.) Perhaps if this is what I would like I would be better off adding a global zone vfstab entry to mount nfsserver:/vol/zones somewhere and use the path:/// uri instead. Thoughts? i'm not sure i understand how you would like to see this functionality behave. wrt vfstab, i'd rather you not use that since that moves configuration outside of zonecfg. so later, if you want to migrate the zone, you'll need to remember about that vfstab configuration and move it as well. if at all possible i'd really like to keep all the configuration within zonecfg(1m). perhaps you could explanin your issues with the currently planned approach in a different way to help me understand it better? The key thing here is that all of my zones are served from one or two NFS servers. Let's pretend that I have a T5440 with 200 zones on it. The way the proposal is written, I would have 200 mounts in the global zone of the form: $nfsserver:/vol/zones/zone$i on /var/zones/nfsmount/nfsserver/vol/zones/zone$i When in reality, all I need is a single mount (subject to implementation-specific details, as discussed above with ro vs. rw shares): $nfsserver:/vol/zones on /var/myzones/nfs/$nfsserver/vol/zones If my standard global zone deployment mechanism adds a vfstab entry for $nfsserver:/vol/zones and configure each zone via path:/// I avoid a storm of NFS mount requests at zone boot time as the global zone boots. The NFS mount requests are UDP-based RPC calls, which sometimes get lost on the wire. The timeout/retransmit may be such that we add a bit of time to the overall zone startup process. Not a huge deal in most cases, but a confusing problem to understand. In this case, I wouldn't consider the NFS mounts as being something specific to a particular zone. Rather, it is a common configuration setting across all members of a particular zone farm. so if your nfs server is exporting a bunch of filesystems like: $nfsserver:/vol/zones/zone$i then yes, you'll end up with mounts for each. but if your nfs server is exporting $nfsserver:/vol/zones then you'll only end up with one. that said, if your nfs server is exporting $nfsserver:/vol/zones $nfsserver:/vol/zones/zone$i i really don't see any way to avoid having mounts for each zone. afaik, if the nfs server has a nested export, the exported subdirectory is only accessible via a mount. so you couldn't mount $nfsserver:/vol/zones and then access $nfsserver:/vol/zones/zone5 without first mounting $nfsserver:/vol/zones/zone5. (i could always be wrong about this, but this is my current
Re: [zones-discuss] zones in opensolaris (os200811) differs from zones in solaris 10?
On Thu, Apr 30, 2009 at 09:33:57AM -0600, Jerry Jelinek wrote: solarg wrote: hello all, i'm wondering how to create a sparse zone in os2008.11: Sparse zones are not currently supported on opensolaris. This is tracked as: 2550 Support for sparse root zones - in solaris 10, just use create instead of create -b does a sparse zone - in os2008.11, you have to add manually: add inherit-pkg-dir set dir=/lib end add inherit-pkg-dir set dir=/platform end add inherit-pkg-dir set dir=/sbin end add inherit-pkg-dir set dir=/usr end Don't do that. The IPS pkg software does not currently support the concept of a sparse zone. The inherit-pkg-dir directive is intimately tied to the packaging software. Only the svr4 pkg software supports sparse zones right now. to help avoid this type of confusion in the future i just filed: 8567 ipkg zones verify callback should abort if it sees inherit-pkg-dir ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris10 brand project proposal
+1 On Thu, Apr 23, 2009 at 10:02:40AM -0600, Jerry Jelinek wrote: I would like to propose a project to be sponsored by the zones community. This project would create a solaris10 branded zone for use on OpenSolaris. We will use the BrandZ infrastructure to deliver a solaris10 brand. This will be provided as an adoption and compatibility aid to enable users currently running S10 to easily adopt OpenSolaris while also continuing to run their S10 software within branded zones. As with the existing solaris8 and solaris9 brands on Solaris 10, this project will provide a 'physical to virtual' (p2v) capability that can migrate an existing S10 software stack on a physical system into a solaris10-branded zone running on a OpenSolaris system. In addition, the project will provide a 'virtual to virtual' (v2v) capability that can migrate existing native S10-based zones into solaris10-branded zones running on a OpenSolaris system. This brand would be available on all architectures that run OpenSolaris (sun4u, sun4v and x86). We've started working on this in the zones team. It will be hard for the community to actually contribute to the emulation layer since the Solaris 10 source code in not open sourced, but we would like to have the full source for the brand and its emulation be open source and part of OpenSolaris. The community could easily contribute to the p2v v2v code as well as provide feedback on the brand itself. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [brandz-discuss] Update Grants, Merge BrandZ and Zones Communities
On Tue, Feb 10, 2009 at 03:01:25PM -0800, Dan Price wrote: ... hey dan, thanks for doing this. +1 on the merger of the two communities. i also accept my core contributor nomination. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Choice of fs type
it depends on your requirements. since you haven't specified any, i'll just say that i prefer using zfs over ufs. hence i'd just recommend adding a zfs dataset via zonecfg. ed On Thu, Jan 22, 2009 at 10:44:09PM +1100, Anthony Yeung wrote: There are a number of ways to mount storage from the global zone to a non-global zone. What are the differences and how to choose? Thanks, Anthony ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Solaris 8 Zones Cleanup
well, certainly you could remove packages, but why bother. disk space is cheap. ed On Wed, Jan 21, 2009 at 07:20:31PM +0100, Bernd Schemmer wrote: Hi, we successfully installed some Solaris 8 zones and I'm wondering if I should delete some of the not necessary packages from the Solaris 8 Zones. I already removed the Veritas packages (VxVM, VxFS, and some VCS packages) Should I also delete some of the plain Solaris 8 packages that are not usable in Solaris 8 Zones? There's not much information about configuring Solaris 8 zones on the Sun Website regards Bernd -- Bernd Schemmer, Frankfurt am Main, Germany http://home.arcor.de/bnsmb/index.html M s temprano que tarde el mundo cambiar . Fidel Castro ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
