Re: [zones-discuss] Branded zones and external hardware
On 08/05/10 07:03, joerg.schill...@fokus.fraunhofer.de wrote: Frank Batschulat (Home)frank.batschu...@sun.com wrote: the problem with exporting the tape device to a NGZ, which although not supported can be achived as you mention, is that there's no way to exclusive assign that particular tape device to a particular NGZ or to restrict access from the GZ or any other NGZ to that same tape device. that might become a problem if several different users try to use that tape from different NGZs or a NGZ and the GZ, that access may produce a somewhat questionable end result that care must be taken here when setting up such configuration. Where do you see a difference from many different users trying to access the same tape from the Global Zone? The difference is that in the global zone there is the possibility for applications to coordinate with each other because they have visibility into what each is doing, whereas in non-global zones there is no visibility from one zone to another. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can a guest LDOM discover the identity of the host system?
On 07/02/10 13:47, Richard L. Hamilton wrote: That is...is there a mechanism provided to do this? As an afterthought, this also applies to non-global zones, although one can stick something in the oem-banner eeprom variable that is identically visible on all the zones, which is not the case on LDOMs. We're tracking this as: 6487259 need a way to find global zone address and/or host name within non-global zone Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Duplicating zones ??
On 06/30/10 04:34, Warren Zeeman wrote: Hello, IHAC who wants to duplicate a global zone, as a zone on another server !!! Does anybody have any thoughts on the easiest way to achieve this ? We call this p2v (physical to virtual). Its been in opensolaris for quite a while now, so if you running a fairly recent build you already have this. I blogged about this early in 2009. http://blogs.sun.com/jerrysblog/entry/zones_p2v Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] booting zone after system restart fails with ERROR: no active dataset
On 05/30/10 16:45, Ian Collins wrote: I've tracked down the cause. It was my backup copy of the zone ZFS tree on another pool: backup/zoneRoot 1.64G 89.3G 26K /backup/zoneRoot backup/zoneRoot/svn 439M 89.3G 24K /backup/zoneRoot/svn backup/zoneRoot/svn/ROOT 439M 89.3G 21K legacy backup/zoneRoot/svn/ROOT/zbe 439M 89.3G 437M legacy Even though the mountpoints and ZFS names differ, their presence appears to have been causing confusion. When I export the backup pool, all boots and creates work. So my problem is solved, but there appears to be an issue with keeping backup copies on the same machine. Can you file a bug on this at defect.opensolaris.org under product: pkg, component: zones. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] booting zone after system restart fails with ERROR: no active dataset
On 05/26/10 17:14, Ian Collins wrote: I have just restarted a b133 host with several zones and no none of them will boot. They all report: # zoneadm -z svn boot zone 'svn': ERROR: no active dataset. zone 'svn': zoneadm: zone 'svn': call to zoneadmd failed I've seen this mentioned as an issue after an upgrade, but this system only has one BE (the active one) and all I have done is a restart. Is there any way to get them back? You haven't provided any information to enable anyone to help you. Are the datasets still there? What does 'zfs list' show? What is the zonepath of one of the zones which won't boot? Did you do anything with your BE's on this system since you installed the zone? Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] booting zone after system restart fails with ERROR: no active dataset
On 05/28/10 15:16, Ian Collins wrote: On 05/29/10 12:25 AM, Jerry Jelinek wrote: On 05/26/10 17:14, Ian Collins wrote: I have just restarted a b133 host with several zones and no none of them will boot. They all report: # zoneadm -z svn boot zone 'svn': ERROR: no active dataset. zone 'svn': zoneadm: zone 'svn': call to zoneadmd failed I've seen this mentioned as an issue after an upgrade, but this system only has one BE (the active one) and all I have done is a restart. Is there any way to get them back? You haven't provided any information to enable anyone to help you. I thought I had, all I did was a reboot. Are the datasets still there? Yes. What does 'zfs list' show? rpool 46.3G 542G 81.5K /rpool rpool/ROOT 5.98G 542G 21K legacy rpool/ROOT/opensolaris 5.98G 542G 5.93G / rpool/build 438M 542G 424M /build rpool/depot 42K 542G 24K /depot rpool/dump 3.00G 542G 3.00G - rpool/export 16.0M 542G 23K /export rpool/export/home 16.0M 542G 23K /export/home rpool/export/home/admin 15.9M 542G 15.9M /export/home/admin rpool/on 545M 542G 545M /rpool/on rpool/play 17.0G 542G 27K /rpool/play rpool/play/test 6.68G 542G 6.68G /rpool/play/test rpool/play/vol10G 10.3G 552G 21.5M - rpool/swap 3.28G 545G 52.3M - rpool/vdi 14.2G 542G 13.9G /vdi rpool/zoneRoot 1.28G 542G 26K /zoneRoot rpool/zoneRoot/svn 439M 542G 24K /zoneRoot/svn rpool/zoneRoot/ftp 472M 542G 24K /zoneRoot/ftp rpool/zoneRoot/ftp/ROOT 472M 542G 21K legacy rpool/zoneRoot/ftp/ROOT/zbe 472M 542G 470M legacy rpool/zoneRoot/ldap 32.9M 542G 25K /zoneRoot/ldap rpool/zoneRoot/ldap/ROOT 32.9M 542G 21K legacy rpool/zoneRoot/ldap/ROOT/zbe 32.8M 542G 369M legacy rpool/zoneRoot/pdc 369M 542G 24K /zoneRoot/pdc rpool/zoneRoot/pdc/ROOT 369M 542G 21K legacy rpool/zoneRoot/pdc/ROOT/zbe 369M 542G 366M legacy None of the zones boot. What is the zonepath of one of the zones which won't boot? Did you do anything with your BE's on this system since you installed the zone? zonepath=/zoneRoot/svn ls /zoneRoot/svn/ dev root There is only one BE. the system was installed with b133. The svn zone won't boot because there is no zfs dataset for the zonepath root. There should be two datasets named rpool/zoneRoot/svn/ROOT and rpool/zoneRoot/svn/ROOT/zbe. You might be able to determine some information about what happened using the 'zpool history' command. That would show you if the dataset was created and then later destroyed. That might give you a clue when that happened and you could try to narrow down what happened from there. It looks like you have datasets for other zones with zonepaths of /zoneRoot/ftp, /zoneRoot/ldap and /zoneRoot/pdc. What is the error you get when you try to boot one of those zones? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] impossible to attach migrated zone to a new server
On 05/19/10 12:47, Philippe Bürgisser wrote: Hi, I followed the guide (http://docs.sun.com/app/docs/doc/819-2450/gcgnc?l=ena=view) from sun to move a working zone into a new server with the same configuration. I executed those commands : tar xf myzone.tar -- to /export/zones/myzone zonecfg -z myzone create -a /export/zones/myzone all was ok when I wanted to attach, I got this message r...@ns358375:/# zoneadm -z proxiproduits attach -u pkg: No image rooted at '/export/zones/proxiproduits/root' (set by $PKG_IMAGE) These two commands don't match up. When you ran: zonecfg -z myzone create -a /export/zones/myzone You created a zone named myzone. When you ran: zoneadm -z proxiproduits attach -u You are operating on a different zone named proxiproduits. You should run: zoneadm -z myzone attach -u Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] update from 111b to 134
On 03/17/10 08:21 AM, Piotr Jasiukajtis wrote: Hi, After upgrade from 111b to b134 non local zone is not able to run properly. Was this a newly installed zone or one that existed from before the upgrade? If it was a pre-existing zone, did you upgrade the software inside the zone to be in sync with the global zone? If so, how? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] update from 111b to 134
On 03/17/10 09:16 AM, Piotr Jasiukajtis wrote: The zone was installed and running before the update. System was upgraded by using 'pkg image-update'. No different actions ware done. In that case, the zone is in an undefined state and unusable. See: http://blogs.sun.com/jerrysblog/entry/updating_zones_on_opensolaris_2008 and the ipkg(5) man page. This situation is a temporary problem until the full zones support is provided with IPS. Jerry On Wed, Mar 17, 2010 at 3:58 PM, Jerry Jelinekgerald.jeli...@sun.com wrote: On 03/17/10 08:21 AM, Piotr Jasiukajtis wrote: Hi, After upgrade from 111b to b134 non local zone is not able to run properly. Was this a newly installed zone or one that existed from before the upgrade? If it was a pre-existing zone, did you upgrade the software inside the zone to be in sync with the global zone? If so, how? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Help, my zone's dataset has disappeared!
On 02/26/10 07:03, Jesse Reynolds wrote: Hello I have an amd64 server running OpenSolaris 2009-06. In December I created one container on this server named 'cpmail' with it's own zfs dataset and it's been running ever since. Until earlier this evening when the server did a kernel panic and rebooted. Now, I can't see any contents in the zfs dataset for this zone! The server has two disks which are root mirrored with ZFS: # zpool status pool: rpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror ONLINE 0 0 0 c8t0d0s0 ONLINE 0 0 0 c8t1d0s0 ONLINE 0 0 0 errors: No known data errors Here are the datasets: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 161G 67.6G 79.5K /rpool rpool/ROOT 3.66G 67.6G19K legacy rpool/ROOT/opensolaris 3.66G 67.6G 3.51G / rpool/cpmail 139G 67.6G22K /zones/cpmail rpool/cpmail/ROOT 139G 67.6G19K legacy rpool/cpmail/ROOT/zbe 139G 67.6G 139G legacy rpool/dump 2.00G 67.6G 2.00G - rpool/export 7.64G 67.6G 7.49G /export rpool/export/home 150M 67.6G21K /export/home rpool/export/home/jesse 150M 67.6G 150M /export/home/jesse rpool/repo 6.56G 67.6G 6.56G /rpool/repo rpool/swap 2.00G 69.4G 130M - /zones/cpmail is where it should be mounting the zone's dataset, I believe. Here's what happens when I try and start the zone: # zoneadm -z cpmail boot could not verify zfs dataset mailtmp: dataset does not exist zoneadm: zone cpmail failed to verify So the zone is trying to find a dataset 'mailtmp' and failing because it doesn't exist. So, what happened to it? Here's the zone config file, at /etc/zones/cpmail.xml (with IP address obfuscated) # cat /etc/zones/cpmail.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE zone PUBLIC -//Sun Microsystems Inc//DTD Zones//EN file:///usr/share/lib/xml/dtd/zonecfg.dtd.1 !-- DO NOT EDIT THIS FILE. Use zonecfg(1M) instead. -- zone name=cpmail zonepath=/zones/cpmail autoboot=false brand=ipkg network address=xxx.xxx.xxx.xxx physical=bge1/ dataset name=mailtmp/ /zone I just don't understand where the dataset 'mailtmp' went to. Perhaps it was an initial name I used for the dataset and I then renamed it to cpmail, but then I can't see any of the zones files in /zones/cpmail : # find /zones/cpmail/ /zones/cpmail/ /zones/cpmail/dev /zones/cpmail/root Does ZFS store a log file of all operations applied to it? It feels like someone has gained access and run 'zfs destroy mailtmp' to me, but then again it could just be my own ineptitude. With the version of opensolaris that you're running, the zone's root dataset won't be mounted until the zone boots. You can see this in the 'zfs list' output above where the mountpoint is legacy and you can look at the zfs mounted property as well. Since the zone is configured with a dataset that doesn't exist, it can't boot so the zonepath dataset isn't mounted. You can use the 'zpool history' command to see what zfs operations were done. I don't know why the mailtmp dataset no longer exists. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Help, my zone's dataset has disappeared!
On 02/26/10 07:37, Jerry Jelinek wrote: On 02/26/10 07:03, Jesse Reynolds wrote: Hello I have an amd64 server running OpenSolaris 2009-06. In December I created one container on this server named 'cpmail' with it's own zfs dataset and it's been running ever since. Until earlier this evening when the server did a kernel panic and rebooted. Now, I can't see any contents in the zfs dataset for this zone! The server has two disks which are root mirrored with ZFS: # zpool status pool: rpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror ONLINE 0 0 0 c8t0d0s0 ONLINE 0 0 0 c8t1d0s0 ONLINE 0 0 0 errors: No known data errors Here are the datasets: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 161G 67.6G 79.5K /rpool rpool/ROOT 3.66G 67.6G 19K legacy rpool/ROOT/opensolaris 3.66G 67.6G 3.51G / rpool/cpmail 139G 67.6G 22K /zones/cpmail rpool/cpmail/ROOT 139G 67.6G 19K legacy rpool/cpmail/ROOT/zbe 139G 67.6G 139G legacy rpool/dump 2.00G 67.6G 2.00G - rpool/export 7.64G 67.6G 7.49G /export rpool/export/home 150M 67.6G 21K /export/home rpool/export/home/jesse 150M 67.6G 150M /export/home/jesse rpool/repo 6.56G 67.6G 6.56G /rpool/repo rpool/swap 2.00G 69.4G 130M - /zones/cpmail is where it should be mounting the zone's dataset, I believe. Here's what happens when I try and start the zone: # zoneadm -z cpmail boot could not verify zfs dataset mailtmp: dataset does not exist zoneadm: zone cpmail failed to verify So the zone is trying to find a dataset 'mailtmp' and failing because it doesn't exist. So, what happened to it? Here's the zone config file, at /etc/zones/cpmail.xml (with IP address obfuscated) # cat /etc/zones/cpmail.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE zone PUBLIC -//Sun Microsystems Inc//DTD Zones//EN file:///usr/share/lib/xml/dtd/zonecfg.dtd.1 !-- DO NOT EDIT THIS FILE. Use zonecfg(1M) instead. -- zone name=cpmail zonepath=/zones/cpmail autoboot=false brand=ipkg network address=xxx.xxx.xxx.xxx physical=bge1/ dataset name=mailtmp/ /zone Sorry for the second response. One more thing looks wrong. The zone is configured with a dataset named mailtmp. That looks wrong since your zpool is named rpool, so I would expect that the dataset would be named something like rpool/mailtmp or something like that. Is it possible you reconfigured this zone at some point but never tried to reboot it? It looks like the dataset you added is just incorrect for your zfs configuration. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Help, my zone's dataset has disappeared!
On 02/26/10 07:56, Jesse Reynolds wrote: Thanks Jerry! Yes, dataset=mailtmp looks wrong. I guess it's possible I altered the configuration and hadn't rebooted it. So, assuming that the manifest is out of date or wrong, what's the best way to fix it? Can I edit /etc/zones/cpmail.xml directly, or should I run zonecfg interactively? Can I just point the zone config at the dataset rpool/cpmail/ROOT and hope for the best? No, don't edit the xml file. Just use zonecfg to edit the zone and delete or change the dataset. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] minor code review for 6890415 6880288 (zoneadm.c, native brand)
On 02/22/10 09:40, Frank Batschulat (Home) wrote: May I have 2 code reviewers for the following minor changes for: PSARC/2010/008 Remove zoneadm install sub-option -x nodataset 6880288 retire zoneadm install -x nodataset option 6890415 zoneadm install fails but returns 0 http://cr.opensolaris.org/~batschul/nodataset/ Frank, This looks good to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] codereview for 6914152 (zonecfg)
On 02/19/10 06:53, Frank Batschulat (Home) wrote: May I request 2 code reviewers for the changes for: 6914152 zonecfg fails when less(1M) is missing http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6914152 http://cr.opensolaris.org/~batschul/zpager/ Frank, This looks fine to me. One nit: 911 5192 The error says Could not stat PAGER. This error message might be useful to a developer but isn't that useful for a sysadmin. Can you print something more meaningful like PAGER %s does not exist or something along those lines. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] codereview for 6914152 (zonecfg)
On 02/19/10 11:32, Frank Batschulat (Home) wrote: Thanks Jerry, that is indeed a valid concern, I changed it to be: snip PAGER /usr/bin/nonsense does not exist (No such file or directory). snip end I included the real error string in case of permission errors where the file does indeed exist and I am now dropping the mysterious stat part. updated webrev: http://cr.opensolaris.org/~batschul/zpager/ LGTM. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] 6715679 - update on attach handling of /etc/release
On 01/27/10 12:30, Marcel Hofstetter wrote:
Jerry Jelinek wrote:
usr/src/lib/brand/native/zone/sw_support.c
1115
1116 } else if (strcmp(buf, SUNW_PKG_ALL_ZONES) ==
0) {
1117 infop-zpi_all_zones = B_TRUE;
1118
My thought is that if the package name is SUNWsolnm,
infop-zpi_all_zones should be B_TRUE.
I will file a bug to add this pkg to the dependent list whenever there
are other pkgs on the list.
Hi Jerry
Just upgraded a Zone from U7 to U8 and /etc/release is updated,
but SUNWsolnm isn't. Of course pkgchk complains.
Is there no open bug?
6700799 update on attach misses SUNWsolnm pkg
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Downgrading zones on Opensolaris 2009.x ( b131)
On 01/25/10 04:30, Paul van der Zwan wrote: I have upgraded my Opensolaris system to b131 and followed the zoneadm detach/attach -u procedure to upgrade my zones to b131 as well. Unfortunately I am running into bug 6912829 ( causes panic on zoneadm halt ) quite often. Downgrading the global zone by beadm activating my old be is easy. But how do I get my zones back ? Zoneadm attach complains that the zone is a newer rev than the global zone and that the global zone should be upgraded… Unfortunately it sounds like you detached your zones before doing the image-update. If you do the image-update, then reboot, then detach/attach, then you will have a zone root for each BE and booting back is no problem. However, if you detach before the image-update, then you only have one zone root and once you've updated that to match the new BE, then there is no way to downgrade it if you boot back. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Downgrading zones on Opensolaris 2009.x ( b131)
On 01/25/10 06:12, Paul van der Zwan wrote: Ok that’s what I did. Detach first and then the image-update. I saw a workaround for the panics so downgrading may be less important, but I’ll have to change my procedure the next update. Do you know of an ‘official’ zones/beadm/image-update doc that explains the correct procedure somewhere ? We're currently in the process of updating the docs for the 2010.03 release so this should be covered better when thats done. I blogged a bit about this for the 2008.11 release: http://blogs.sun.com/jerrysblog/entry/updating_zones_on_opensolaris_2008 http://blogs.sun.com/jerrysblog/entry/zones_on_opensolaris_2008_11 Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] why are zone datasets mounted when no zone is running ?
On 01/22/10 04:57, Frank Batschulat (Home) wrote: Hiya, I observed that zone datasets are mounted even though no zones are running. this strikes me like a bug ? aren't they supposed to be mounted only when the zone boots ? No, it was a bug that they weren't mounted except when the zone was running. See: 3979 zone fs only available from Global zone, when zone is booted Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] SXCE b130 zoneadm attach -u error
On 01/18/10 19:25, Karl Rossing wrote: I made the change as per http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6905313 What changes? As of this morning the bug has no workaround or suggested fix listed? I'm still getting the following error: bash-4.0# zoneadm -z model attach -u Getting the list of files to remove Removing 45892 files svccfg: pg_pattern is missing the target attribute in system/rmtmpfiles svccfg: pg_pattern is missing the target attribute in system/boot-config I/O error : Is a directory /a/var/svc/manifest/application/desktop-cache:1: parser error : Document is empty ^ /a/var/svc/manifest/application/desktop-cache:1: parser error : Start tag expected, '' not found ^ I/O error : Is a directory svccfg: couldn't parse document rm: /a/var/svc/manifest/application/desktop-cache is a directory Remove 578 of 578 packages Installing 42309 files /usr/lib/brand/native/attach_update[635]: syntax error at line 644 : `' unmatched This looks like you made some sort of incorrect edit to this file. zone 'model': 'attach_update' failed with exit code 2. could not update zone bash-4.0# zoneadm -z model attach -u zoneadm: zone 'model': zone is incomplete; uninstall required. Any suggestions on how to fix this? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
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? Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Webrev for CR 6909222
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 Jordan, This looks ok to me but don't we need to do a similar fix for the ipkg brand since we can also do p2v with that brand? Can you file a bug to track that? Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Webrev for CR 6909222
Jordan Vaughan wrote: On 01/ 4/10 07:26 AM, Jerry Jelinek wrote: 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 Jordan, This looks ok to me but don't we need to do a similar fix for the ipkg brand since we can also do p2v with that brand? Can you file a bug to track that? Thanks, Jerry Hi Jerry, Thanks for reviewing my fix. Won't package variants solve the problem for the ipkg brand? Jordan, I don't think so since the boot_archive files are not delivered by any pkg. Thus, there is nothing in the change-variant process which will touch those files. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Webrev for CR 6909222
Jordan Vaughan wrote: On 01/ 4/10 09:54 AM, Jerry Jelinek wrote: Jordan Vaughan wrote: On 01/ 4/10 07:26 AM, Jerry Jelinek wrote: 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 [...] Jordan, I don't think so since the boot_archive files are not delivered by any pkg. Thus, there is nothing in the change-variant process which will touch those files. Thanks, Jerry /boot/solaris/bin/create_ramdisk is installed by SUNWckr, right? ---8--- jv227347 arrakis [10:13:45 0]% pkg search /boot/solaris/bin/create_ramdisk INDEX ACTION VALUE PACKAGE path file boot/solaris/bin/create_ramdisk pkg:/sunwc...@0.5.11-0.79 path file boot/solaris/bin/create_ramdisk pkg:/sunw...@0.5.11-0.108 [...] pkg:/sunw...@0.5.11-0.127 path file boot/solaris/bin/create_ramdisk pkg:/sunw...@0.5.11-0.128 path file boot/solaris/bin/create_ramdisk pkg:/sunw...@0.5.11-0.129 path file boot/solaris/bin/create_ramdisk pkg:/sunw...@0.5.11-0.130 ---8--- Will changing variants not affect SUNWckr? Jordan, Maybe I'm not understanding the bug's evaluation but it seems to say that the problem is caused by the presence of boot archive files. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Webrev for CR 6909222
Jordan Vaughan wrote: Maybe I'm not understanding the bug's evaluation but it seems to say that the problem is caused by the presence of boot archive files. Jerry Jerry, It is. However, bootadm(1M) infers the existence of boot archives from the existence of /boot/solaris/bin/create_ramdisk. If we remove the latter from a zone, then bootadm(1M) won't try to update boot archives in the zone's root filesystem. Changing package variants during ipkg p2v should remove /boot/solaris/bin/create_ramdisk and thus prevent bootadm(1M) from updating ipkg-branded zones' boot archives. Jordan, OK, thanks for the clarification. I just checked the pkg metadata and change-variant will work properly to address this: % pkg contents -m | egrep create_ramdisk file 5e6129cf9f1b34c37c0bd34c2c1feb841dbc9436 chash=0e9054d31e87beecb9eda2e28f70c1ab443ef878 group=sys mode=0555 opensolaris.zone=global owner=root path=boot/solaris/bin/create_ramdisk pkg.csize=5148 pkg.size=14675 variant.opensolaris.zone=global Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
Edward Pilatowicz wrote: 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, Thanks for all of your comments. I'll make the update you suggested. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
Edward Pilatowicz wrote: 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, 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. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
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. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
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/ Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
Edward Pilatowicz wrote: 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--- 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. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6495558
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/ Frank, Looks fine to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
Jordan Vaughan wrote: -- usr/src/lib/brand/sn1/sn1_brand/amd64/sn1_handler.s 44: Shouldn't this function be named sn1_handler_table? Jordan, Good catch, I'll fix that. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
Ed, I've posted an updated webrev to address your comments. http://cr.opensolaris.org/~gjelinek/webrev.6768950/ Let me know if you have any other comments or see anything with the changes I made. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
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. - 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--- Since we don't care about preserving the syscall number that extra instruction has no value. However, I'll take another shot at trying to streamline this a bit. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones code review
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.
this looks great. i have some initial comments.
--
usr/src/lib/brand/{sn1|solaris10}/*_brand/*/*_handler.s:
- could you update the following lines with comments:
xchgq CPTRSIZE(%rbp), %rax/* swap JMP table offset and ret addr */
shrq$4, %rax/* JMP table offset / JMP size = syscall num */
movq%rax, EH_LOCALS_GREG(REG_RAX)(%rbp) /* save syscall num */
Will do.
--
usr/src/uts/i86pc/ml/syscall_asm.s:
- don't you need to update this file as well? have you tested 32-bit
kernels?
No, this doesn't need to be updated since this code doesn't touch the
user's stack. I have done preliminary testing with 32 bit kernels and
the callbacks work correctly with the code as is. Thats because the
32 bit code is more like the 64 bit code that handles an interrupt stack
where we already have the right data pushed.
--
usr/src/uts/i86pc/ml/syscall_asm_amd64.s
- perhaps you could do the following renames:
BRAND_GET_RET_REG - BRAND_URET_FROM_REG
BRAND_GET_RET_STACK - BRAND_URET_FROM_INTR_STACK
Will do.
- wrt this code:
cmpq$NSYSCALL, %rax /* is 0 = syscall = MAX? */
jbe 0f /* yes, syscall is OK */
xorq%rax, %rax /* no, zero syscall number */
it's duplicated in every brand callback right after
CALLBACK_PROLOGUE(). why not make it part of CALLBACK_PROLOGUE?
Will do.
also, if the syscall num is NSYSCALL, why not just jump to 9: and
let the normal syscall path detect and return the error?
OK. I was modeling this on the way lx did it but your suggestion seems
better.
- it seems like there should be a macro for this rough block of code
(which calculates the jmp table address):
GET_P_BRAND_DATA(%esp, 1, %edx);/* get p_brand_data ptr */
movlSPD_HANDLER(%edx), %edx /* get p_brand_data-spd_handler ptr */
shll$4, %eax
addl%eax, %edx /* we'll return to our handler */
I'll put one together.
- 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
Re: [zones-discuss] code review for 6495558
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. Frank, Looks fine to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris 10 branded zone
xx wrote: i installed virtualbox and installed solaris 10 from an iso download. i used the flar command to create s10.flar as directed in: http://hub.opensolaris.org/bin/view/Community+Group+zones/s10brand_dev_guide i then tried to install s10.flar in the solaris 10 branded zone: init...@dogpatch:~# zoneadm -z csuite install -a /virtualbox/s10.flar -u WARNING: skipping network interface 'vnic0_3' which may not be present/plumbed in the global zone. A ZFS file system has been created for this zone. Log File: /var/tmp/csuite.install_log.2raajz Installing: This may take several minutes... Missing etc at /zones/csuite/root Missing etc/svc at /zones/csuite/root Missing var at /zones/csuite/root Missing var/svc at /zones/csuite/root Missing lib/svc at /zones/csuite/root Is this a sparse zone image? The image must be whole-root. Missing sbin/zonename at /zones/csuite/root Is this a sparse zone image? The image must be whole-root. Missing usr/bin/chmod at /zones/csuite/root Is this a sparse zone image? The image must be whole-root. Sanity Check: FAILED (see log for details). ERROR: Result: *** Installation FAILED *** init...@dogpatch:~# zonecfg -z csuite info zonename: csuite zonepath: /zones/csuite brand: solaris10 autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: net: address: 192.168.30.4 physical: vnic0_3 defrouter not specified init...@dogpatch:~# did i skip a step? How did you create the flar of the s10 system? Did the s10 system have a zfs root? If so, then you must create the flar using an explicit -L option to specify either a cpio or pax archive. Otherwise the flar will actually contain a zfs send stream of the root pool and that is not suitable for installing a zone (since the zone root must be a dataset, not a pool). I recently integrated the following bug fix to help address this: 6903478 need better error msg for flar made on system with zfs root Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] why not just bury zoneadm [-x nodataset] option ?
Frank Batschulat (Home) wrote: friends, I went back and forth with th bug pertaining the [-x nodataset] option 6880288 zoneadm install -x nodataset option should be brand-specifc http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6880288 and eventually I decided to ask for quorum to just bury this option entirely. When Jerry filed it, his intent was to make it brand specific as that option means no zfs dataset should be created for a zoneroot. the zone will be just put onder a zoneroot directory instead. this really only makes sense for native brands that do not rely on all the fancy beadm/ips features used in OSOL. point is you can not really make this option brand specific. the code to create datasets is generic (and for obvious reasons should be) and thus lives in zoneadm.c:install_func() and is executed prior calling the brand specific install_func(). so one can only special case this in zoneadm.c:install_func() itself and remove the mentioning of this option from zoneadm.c and put it into the native brands sw_support.c:install_usage() func. however I've been asking around people that use zones pretty much since Solaris 10 came out the door, they do not even know about that option. also I think it would be a reasonable thing to just always have datasets for zoneroots created going forward in terms of managability and usage. it's not applicable to UFS zoneroots and neither to all the other brands except the native brand, which we're not going to use much anymore going forward with the ipkg brand. so may I ask for a positive vote to bury that thing rather then attempting handstands ? that'd be marvellous... Frank, This sounds fine to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris 10 branded zone
xx wrote: init...@dogpatch:/virtualbox# zoneadm -z csuite install -a ./s10.cpio -u WARNING: skipping network interface 'vnic0_3' which may not be present/plumbed in the global zone. A ZFS file system has been created for this zone. Log File: /var/tmp/csuite.install_log.79aGOA Error: Unknown archive format. Must be a flash archive, a cpio archive (can also be gzipped or bzipped), a pax XUSTAR archive, or a level 0 ufsdump archive. ERROR: Installation aborted. do i need to label it as a cpio archive somehow? I think you've hit a bug in the code. Can you re-run the command with an absolute path to the flar. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Solaris10-Branded Zones Webrev: CR 6882732
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 Jordan, Nice job, this looks good to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Upgrade from 127 to 128a blew up all my zones
Robert Hartzell wrote: My normal procedure is to image-update, reboot, check that everything is working then update each zone. This has always worked because the zones would still be running. All my external services are running in zones (dns, smtp, http, ftp) so when I reboot I have no dns and therefore can't update the zones. Not much I can do about the single point of failure so is there a way I can update the zone before I reboot? If zones sometimes appear to work in your example above, then that is simply luck and not by design. It is certain that things will break in that configuration from time to time. If you want to update the zones before updating the global zone then you might be able to halt the zones, detach them, then use the -R option to the pkg command to update the zone's roots. However, I've never tried that. As I said, this is all a temporary limitation until the pkg code is enhanced to automatically keep the zones in sync with the global zone. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Upgrade from 127 to 128a blew up all my zones
Robert Hartzell wrote: I have upgraded 3 systems from 127 to 128a and all the zones basically have the same error. autofs is in maintenance with 17 dependent services not running. I haven't upgraded the zones because they are in production and don't want to have to recreate all 7 of them again. Is this a known issue or am I just the lucky one? I do have one system that I can trouble shoot on if anyone has some ideas. By not upgrading the zones you've put the system into an unknown and unsupported state. The zones must be running the same system software as the global zone. You can use the following sequence of commands to update the zones so that they are in sync with the global zone: # zoneadm -z foo detach # zoneadm -z foo attach -u # zoneadm -z foo attach The second attach is needed to work around a bug in b128. Normally this is not needed. Eventually the image-update code will automatically keep the zones in sync with the global zone but that code is still being designed. In the meantime you have to manually keep the zones in sync as shown above. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ERROR: no active dataset. w/ migration from Indiana snv_125 to Indiana snv_127
John D Groenveld wrote: In message 4b141dac.7060...@sun.com, Jerry Jelinek writes: The workaround for what? On snv_127, zfs receive does not mount the zbe and zoneadm attach fails until its mounted: # uname -v snv_127 # zfs receive -d rpool /var/tmp/foo.snapshot # zonecfg -z foo create -a /var/opt/zones/foo # zfs get mountpoint rpool/var/zones/foo/ROOT/zbe NAME PROPERTYVALUESOURCE rpool/var/zones/foo/ROOT/zbe mountpoint /var/opt/zones/foo/root local # mount | grep /var/opt/zones/foo /var/opt/zones/foo on rpool/var/zones/foo read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=2d9005f on Mon Nov 30 16:01:41 2009 # zoneadm -z foo attach Log File: /var/tmp/foo.attach_log.plaGWe ERROR: no active dataset. # zfs mount rpool/var/zones/foo/ROOT/zbe # zoneadm -z foo attach -u Log File: /var/tmp/foo.attach_log.T9aOnf Attaching... Global zone version: ent...@0.5.11,5.11-0.127:2009T131831Z Non-Global zone version: ent...@0.5.11,5.11-0.125:20091014T044127Z Publisher Check: Looks good. Cache: Using /var/pkg/download. Updating non-global zone: (Stage 1). Output follows DOWNLOAD PKGS FILESXFER (MB) Completed91/91 3191/319180.7/80.7 PHASEACTIONS Removal Phase 2462/2462 Install Phase 2650/2650 Update Phase 4402/4402 Updating non-global zone: (Stage 2). Output follows No updates necessary for this image. Updating non-global zone: Zone updated to ent...@0.5.11,5.11-0.127:2009T131831Z Attach complete. Thats not a workaround, thats what you have to do if you want to set up an attach by hand. The zone's dataset must be accessible when you do a simple attach (i.e. it must be in the same state as if you'd done a detach followed by an attach on the same system). There are a variety of additional options for attach which allow you to automatically attach from an image made on another system. These options will do the proper setup for you. We have an experimental -r option which can be used for zfs send input but I need to do some more work with it and we need some additional automated tests to make sure it is solid. At this point I'm not really sure how well its working. I need to take some time to work with it further. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] quick bug fix webrev...
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 Ed, This looks fine to me. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] one line webrev...
Edward Pilatowicz wrote: hey all, so with my recent zoneadm mount putback i broke the native brand on nevada. i've got a webrev with the one line fix here: http://cr.opensolaris.org/~edp/onnv-zmount2 6898056 native zones no longer boot: zone 'public': missing or invalid brand Ed, looks good to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] webrev for on-nightly zone install fix
Edward Pilatowicz wrote: 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, This looks good to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] restrcit physical memory with zone.max-locked-memory
Ketan wrote: Is it possible to restrict physical memory in solaris zone with zone.max-locked-memory just like we can do with rcapd ? I do not want to used rcapd No, locked memory is not the same thing as the total physical memory used by a zone. The only way to cap physical memory is with rcapd. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] solaris10 branded zone in b127
Yesterday we integrated support for solaris10 branded zones into ON. In case you're not watching the putback notifications, the heads-up message is here: http://onnv.sfbay.sun.com/links/flagdays/pages/2009102201.html We've divided this project up into phases, so whats there now is Phase I. It has all of the basic brand emulation to run Solaris 10u8 or later. For Phase II we'll be adding support for exclusive IP stacks, delegated ZFS datasets, the ability to run these zones on xVM and the ability to upgrade the version of Solaris 10 running inside the zone to a later version of S10. Let us know if you have any comments or questions. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris10 branded zone in b127
Jerry Jelinek wrote: Yesterday we integrated support for solaris10 branded zones into ON. In case you're not watching the putback notifications, the heads-up message is here: http://onnv.sfbay.sun.com/links/flagdays/pages/2009102201.html Sorry, I posted an internal link here. The external link is: http://opensolaris.org/os/community/on/flag-days/pages/2009102201/ Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
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. - 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. - 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. - 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? No, it came from the native p2v, just as the ipkg code did. I made the fix here that I also made for the ipkg work. - 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. -- usr/src/lib/brand/solaris10/s10_support/s10_support.c - 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? I changed this so that we still check for the minimum KU and we now use the optional version file from S10 to determine if we need a specific version of the emulation. - 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. -- usr/src/lib/brand/solaris10/zone/attach.ksh - 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.) I filed the following bug for that enhancement but I don't want to make that part of this project. 6888652 zoneadm attach should try to create a zfs dataset -- usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c - 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. Yes, since these are embedded arrays, they must be copied, we can't simply do an assignment. I did change the uucopy to bcopy so that I didn't have to do the cast. - 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. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Jordan, Thanks for reviewing this again. I took most of your input. For the things I didn't take, I have responded below. Jordan Vaughan wrote: usr/src/uts/common/brand/solaris10/s10_brand.c 1260-1261,1286-1287,1313,etc.: Couldn't we make arg1 a zoneid_t, arg2 an int, arg3 a char *, and arg4 a size_t and eliminate some of the casts in s10_zone() (as well as some of the automatic variables, e.g., buf and bufsize)? Since thats not always the types of the parameters passed, I don't want to change this since it would complicate any work we might do in the future. -- usr/src/lib/brand/solaris10/s10_support/s10_support.c get_image_emul_version(): I agree with Ed that get_image_emul_version() is superfluous. Now that I've thought about it, $ZONEROOT/usr/lib/brand/solaris10/version should be sufficient for the brand to determine whether it can host the associated S10C. All we need to do is hard-code the maximum version number supported by the brand (for example, as a preprocessor constant), fetch the version number stored in $ZONEROOT/usr/lib/brand/solaris10/version (or zero if the file does not exist), check whether the latter exceeds the former, and set the brand's emulation number to that stored in $ZONEROOT/usr/lib/brand/solaris10/version. See my response to Ed on what I did here. The check for the minimal KU is not superfluous, but I did rewrite this as I explained to Ed. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
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. 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? Sorry, I meant get_active_ds(), not get_zonepath_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.) 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.) OK, I misunderstood what you meant. I'll change this. - 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? Sure. -- 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. Sure. -- 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. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
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. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Ed, Edward Pilatowicz wrote: 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.) Sure. I used the file list from your comments but I'll go ahead and paste all of them in. -- 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. Will do. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Peter Memishian wrote: 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. I don't see how that addresses the primary point, which is that Solaris brands seem to suffer from code duplication. Are you asserting that the amount of code duplication between the sn1 and solaris10 brands is unique to that situation and is not something that will occur again when we cons up the next solarisX brand? Yes. If we were to ship another brand that was fundamentally similar to the solaris10 brand (e.g. the solaris9 brand on Solaris Next), then I think it would make sense for that project to try to make more of the code common with the then currently shipping solaris10 brand. However, I don't think that is necessary for a brand we don't ship (but I can also understand if you don't agree with me). Once the solaris10 brand is integrated, I would hope that we would focus our limited resources on the one brand we do ship across all architectures and I would anticipate that the sn1 brand will be of limited usefulness (since its main reason for existence is to test brandz on sparc). If we do anything else with sn1 after this brand integrates is outside the scope of this project and not something we've even discussed (other than my commitment to fix the sn1 brand per Ed's code review comments). Of course, its up to future brand projects to evaluate what makes the most sense for their project and I can't commit those hypothetical projects to anything. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Ed, Edward Pilatowicz wrote: 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. No, that wasn't my thinking, but as I said, we've never discussed the future of the sn1 brand. If we think this is an important issue, we can look at it. From looking at the webrev, I see maybe 11 source files (not counting makefiles, pkging files or configuration files) that might be candidates for commonality (i.e. files with 10% lines of difference). This doesn't seem like a burning issue to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Jordan Vaughan wrote: I have a few nits and questions aside from Ed's. Jordan, Thanks for looking this over. I'll address these once I finish going through Ed's comments. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
Edward Pilatowicz wrote: i'm not done yet, but i've attached what i've got so far. Ed, Thanks for your comments. I'll start to work through these while we're waiting for the rest of your input and respond if there is anything we're not going to address. Thank again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating zones question
Will Fiveash wrote: As an aside it would be nice if the pkg image-update command provided an option to update all zones configured in the BE being updated. There is no option because it will eventually do that automatically, just like upgrading s10 today will also upgrade all zones. We're just not there yet. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
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 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating zones question
Will Fiveash wrote: This is in the FAQ. http://www.opensolaris.org/os/community/zones/faq/#os I wish the info was more detailed/explicit. How do I use zones attach/detach to do an image-update on the zone exactly? # zoneadm -z myzone foo detach # zoneadm -z myzone foo attach -u Also I don't see anything in there on what I need to do if I want to snapshot an existing zone in case I want to rollback the zone to the state it was in prior to the image-update. When you image-update the system that will happen automatically. When you go back to an earlier global zone BE, then the earlier zone BEs will automatically be used. If you want to do something like this independently of the global zone, then you have to roll your own stuff. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Ancestor filesystems writable by zone admin - by design?
Miles Benson wrote: Hi All, I'm not sure what I'm seeing is by design or by misconfiguration. I created a filesystem tank/zones to hold some zones, then created a specific zone filesystem tank/zones/basezone. Then built a zone, setting zonepath=/tank/zones/basezone. If I zlogin to basezone, and do zfs list, it shows the ancestors to basezone tank tank/zones tank/zones/basezone tank/zones/basezone/ROOT tank/zones/basezone/ROOT/zbe This in itself is not ideal - if a zone become compromised then it's revealing something about the underlying pool and filesystems. I can live with it. However, if I become root in the zone then the ancestor filesystem is *writable*. I can write a file in /tank/zones! So if I delegate root access to a zone to someone, all of a sudden they can write to the entire pool? Am I doing something wrong? Any and all suggestions welcome! So how do the higher datasets appear in the namespace of the zone? That is, you're implying that somehow /tank/zones is mounted inside the zone. Is that true? I can't reproduce this on my opensolaris system running b123. Can you provide more details on your zone configuration and what you did to make /tank/zones visible inside the zone. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Ancestor filesystems writable by zone admin - by design?
Miles Benson wrote: Hi Jerry, Ok, that makes sense. And I've checked and you're right, it's all in the non-global zone. My mistake and I'm glad I was wrong. However, I think the thing which set me off on the wrong track in the first place was the zfs list output showing the available space. Which quota is that data space coming out of? The zone's filesystem has a 5G quota and the data filesystem has a 20G quota. zfs list shows these as I'd expect but it shows /tank/zones having the full run of the 2.5T main pool. I'd guess that it's in the 5G basic zone filesystem and that zfs list is just a bit confused? I can't really answer this without seeing the quota's you have set on each dataset. However, the output you sent earlier, which I've included here, seems to show the correct quotas on the two datasets that are actually available inside the zone. This matches up to what you've said above (20GB and 5GB). r...@oberon:~# zfs list NAMEUSED AVAIL REFER MOUNTPOINT tank 93.8G 2.57T 53.6K /tank tank/zones 1.12G 2.57T 41.1K /tank/zones tank/zones/pauldata 390M 19.6G 390M /tank/zones/pauldata tank/zones/pauldata/svnrepository 105K 19.6G 105K /tank/zones/pauldata/svnrepository tank/zones/paulzone 404M 4.61G 37.5K /tank/zones/paulzone tank/zones/paulzone/ROOT404M 4.61G 34.0K legacy tank/zones/paulzone/ROOT/zbe404M 4.61G 701M legacy I'm unclear why the size of the datasets that aren't available inside the zone is a concern, other than that you'd prefer those to not be visible at all. That's really not a zone's issue and would be more appropriate to discuss over on the zfs alias. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand Phase I webrev
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. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating zones question
Will Fiveash wrote: On Mon, Sep 28, 2009 at 12:20:53PM -0600, Jerry Jelinek wrote: Will Fiveash wrote: This is in the FAQ. http://www.opensolaris.org/os/community/zones/faq/#os I wish the info was more detailed/explicit. How do I use zones attach/detach to do an image-update on the zone exactly? # zoneadm -z myzone foo detach # zoneadm -z myzone foo attach -u The man page for zoneadm does not describe the -u flag for attach. It is also unclear to me which zoneadm parameter foo represents. Sorry, I mistyped the example. It should have been: # zoneadm -z myzone detach # zoneadm -z myzone attach -u The string foo should not have been in the example. The -u flag is not in the zoneadm man page because it is a brand specific option. Not all brands support -u (e.g. lx does not). There is no man page for the ipkg brand yet but you can read about this option on the native(5) man page. Given I created and updated a BE by doing: beadm create opensolaris_123 beadm mount opensolaris_123 /mnt pkg -R /mnt image-update and I have a non-local zone called master, can you provide the exact commands I should have run in order for the master zone to be updated to snv_123 when I boot the opensolaris_123 BE and still have be able to access a master zone at snv_111 when I boot the opensolaris_111 BE? Is this what I should have done: beadm create opensolaris_123 beadm mount opensolaris_123 /mnt zoneadm -z master detach pkg -R /mnt image-update zoneadm -z master attach -u More like: beadm create opensolaris_123 beadm mount opensolaris_123 /mnt pkg -R /mnt image-update zoneadm -R /mnt -z master detach zoneadm -R /mnt -z master attach -u Although I haven't tested that to see if the ipkg brand will handle the zone update correctly on an alternate root. If not, thats a bug in the brand. I do know that booting the opensolaris_123 BE then detaching/attaching the zone will properly update the zone. We're still working on getting IPS and zones to work properly together so that the zones get updated when you image-update the global zone. ? Do I need to recreate the opensolaris_123 BE and do the above in order to get the master zone properly updated? No, if you're running opensolaris_123, just detach the zone then attach -u and the right thing should happen. If the zone is already up-to-date, then the zone will simply be attached. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] updating zones question
William A. Fiveash wrote: My questions are: - Should the zones have been updated when I did the pkg -R /mnt image-update to BE opensolaris_123? - If not, how can I fix the zones so that when I boot them while running the opensolaris_123 BE they have 123 level packages and if I run in the opensolaris_111 BE the zones have 111 packages install? This is in the FAQ. http://www.opensolaris.org/os/community/zones/faq/#os Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] s10 brand Phase I webrev
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
Re: [zones-discuss] s10 brand Phase I webrev
Peter Memishian 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. I see that ip-type=exclusive is regarded as experimental in s10_support.c; is that planned for Phase II? Yes, that's right. We haven't done any of the testing or evaluation yet on what it will take to make exclusive fully work for the brand but we will do that for Phase II. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones patching issues using attach -u
Gael wrote: Hello I have been experimenting a few ways to speed up patching a bunch of machines running whole zones (parallel patching, zoneadm attach -u). I have encountered one issue with the attach -u way... Before initiating a case with sun, I was wondering if it was a well known issue... The GZ is initially running Solaris 10 U6 with kernel patch 13-08 (and other patches from the same period). I start by applying 119254-70, 119313-28 and 12-05 while the machine is in multiuser mode, then I shutdown and detach the zones. I bring back the machine in single user mode and apply a collection of about 190 patches (smpatch analyze output from a few days ago) which brings the machine at the kernel version 141414-10. The patching appears to go fine for the GZ apss8003:/var/sadm/patch #pkginfo -p apss8003:/var/sadm/patch # But when zoneadm attaching -u the zones, pkginfo reports multiple partially failing packages adds ... apss8003:/var/sadm/patch #zlogin test pkginfo -p system SUNWcsr Core Solaris, (Root) system SUNWgsscGSSAPI CONFIG V2 system SUNWkrbrKerberos version 5 support (Root) system SUNWntprNTP, (Root) system SUNWppror PatchPro core functionality (Root) system SUNWsacom Solstice Enterprise Agents 1.0.3 files for root file system # cat /zones/test/root//var/sadm/system/logs/update_log | egrep partially|corrupt|pathname does not exist| = SUNWcsr pkgadd: ERROR: source path /var/sadm/pkg/SUNWcsr/save/pspool/SUNWcsr/reloc/var/svc/manifest/network/ldap/client.xml is corrupt pathname does not exist Installation of SUNWcsr on zone test partially failed. = SUNWgssc pkgadd: ERROR: source path /var/sadm/pkg/SUNWgssc/save/pspool/SUNWgssc/reloc/var/svc/manifest/network/rpc/gss.xml is corrupt pathname does not exist Installation of SUNWgssc on zone test partially failed. = SUNWkrbr pkgadd: ERROR: source path /var/sadm/pkg/SUNWkrbr/save/pspool/SUNWkrbr/reloc/var/svc/manifest/network/security/kadmin.xml is corrupt pathname does not exist Installation of SUNWkrbr on zone test partially failed. = SUNWntpr pkgadd: ERROR: source path /var/sadm/pkg/SUNWntpr/save/pspool/SUNWntpr/reloc/var/svc/manifest/network/ntp.xml is corrupt pathname does not exist Installation of SUNWntpr on zone test partially failed. = SUNWppror pkgadd: ERROR: source path /var/sadm/pkg/SUNWppror/save/pspool/SUNWppror/reloc/var/svc/manifest/system/installupdates.xml is corrupt pathname does not exist Installation of SUNWppror on zone test partially failed = SUNWsacom pkgadd: ERROR: source path /var/sadm/pkg/SUNWsacom/save/pspool/SUNWsacom/reloc/var/svc/manifest/application/management/snmpdx.xml is corrupt pathname does not exist Installation of SUNWsacom on zone test partially failed. If creating a new zone after the patching, there is no partial packages in that newly build zone. The patch list being a little bit lengthy, I can send it privately when asked... This is bug: 6857294 zoneadm attach leads to partially installed packages I believe a T patch might be available for the S10 SVr4 packaging code if you need it, but I see that the fix has not yet been integrated into the nv SVr4 packaging code. It is scheduled for b124. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] folding brandz into zones on os.o
Edward Pilatowicz wrote: hey all, just a quick heads up. it's been on my todo list for a very long time (and i figured that i really should get it done before the xwiki migration), so i finally merged all the brandz community content into the zones community. you can see all the moved content here: http://opensolaris.org/os/community/zones/brandz The only updates i made to the content in the process of moving it was changes to make links self consistent. (ie, so all the brandz referencing links in the moved pages now point to the new pages.) Ed, This looks good, one question. On the zones page: http://opensolaris.org/os/community/zones/ The only brandz stuff is in the left column. Do you want to add any link in the main body (center columns) to make brandz more visible? Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] prebuilt solaris 10 container pkgs
I've uploaded prebuilt SVr4 pkgs onto the project page for the solaris10 brand that we're building. http://opensolaris.org/os/project/s10brand/ I'll do this from now on as we sync to each nevada build. The current pkgs are meant to be used with b118. The OpenSolaris dev repository should be hosting that soon (next week I think). This might make it easier for people who want to play around with the brand. Since these are development bits, not everything is going to work properly inside the zone but overall it is pretty usable at this point, although we only work with shared stack right now and delegated ZFS datasets don't work yet. Feel free to send us feedback if you try this out and let me know if there are any questions. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Preconfiguring ipkg Brand Zones
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 create the following sysidcfg file:
bleon...@opensolaris:/zones/myzone/root/etc# cat sysidcfg
system_locale=C
terminal=xterms
network_interface=PRIMARY {hostname=myzone}
security_policy=none
name_service=NONE
nfs4_domain=dynamic
timezone=US/Eastern
root_password=changeme
Log into the zone:
pfexec zlogin -C myzone
And then boot it:
pfexec zoneadm -z myzone boot
However, I'm still presented with the interactive sysidcfg. I checked the
sysidconfig.log, but there's not much information to go on:
r...@myzone:/var/log# tail sysidconfig.log
Added entry /lib/svc/method/sshd at Tue Jul 07 13:23:30 2009
Executing Configuration Applications at: Tue Jul 07 10:32:32 2009
Executing config app: /lib/svc/method/sshd
Completed Executing Configuration Applications at: Tue Jul 07 10:32:35 2009
Am I doing something wrong or is this a bug?
You are doing something wrong. This is a FAQ:
http://opensolaris.org/os/community/zones/faq/#os
Readying the zone is the proper way to workaround this for now.
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] What is the status of zones on OpenSolaris?
Ben wrote: Hi all, I have an OpenSolaris server (home server for file serving and SunRay) and am currently virtualising OpenSolaris inside VirtualBox to segregate applications. This is a little resource intensive and I'd like to look at zones as an alternative. Last time I talked to an engineer, zones were broken, if you upgraded the system you had to rebuild your zones (I think I heard this pre-2008.11). Is this still the case? Or does the system do something clever now so that I would reboot into a new BE and the zones could be started as usual? Or was what I heard a load of tosh? The support for zones on opensolaris is still evolving but zones are generally very usable on opensolaris. The issue you are describing did exist a long time ago but as best I know is no longer a problem unless some new bug has cropped up somewhere. However, when you image-update the system now, the zones are also cloned but they are still not automatically updated to be kept in sync with the global zone. We're hoping that support will be added for the next release. To work around this, the easiest thing to do is to detach and reattach each zone using the 'update on attach' option (-a) which will cause the zone to be updated to be in sync with the global zone. The zones faq at: http://opensolaris.org/os/community/zones/faq/#os discusses zones on opensolaris if you want more details about the current status. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] What is the status of zones on OpenSolaris?
Jerry Jelinek wrote: ... added for the next release. To work around this, the easiest thing to do is to detach and reattach each zone using the 'update on attach' option (-a) which will cause the zone to be updated to be in sync with the global zone. Sorry for the typo, the option is -u, not -a. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] s10 brand code review
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
Re: [zones-discuss] s10 brand code review
Jordan Vaughan wrote: I have a few nits. Some of them (such at [3]) might be ridiculously trivial, so I won't complain if you don't take them into account. Jordan, Thanks for reviewing this. I'll make all of the simplifications you suggested. Thanks again, Jerry ___ 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
Ian wrote: Hiya, I've just upgraded my 2008.11 system but the only way I could get it to upgrade was by detaching all my zones or beadm refused to create a new BE. Now that I'm in 2009.06, I used zoneadm -z web attach -F and I can see the zone claims to be installed when using zoneadm list -cv: ID NAME STATUS PATH BRANDIP 0 global running/ native shared - web installed /space/zones/web ipkg shared but when I try to start it I get: zoneadm: zone 'web': call to zoneadmd failed everytime. Have I messed things up by using -F instead of -u when trying to re-attach the zones, or is it stuffed because it was detached during the upgrade process and is therefore still 2008.11 internally ? I've Googled myself in circles so pointers would be very helpful right now (including any way of getting more helpful error messages). I can still see the zone data so I suppose the last resort is to create a new zone now and manually copy the config over, but I have half a dozen or so and it'd get rather tedious. I'm not sure why you had to first detach your zones. There was a bug in beadm on that but I thought it was fixed. The attach -F does nothing except change the state of the zone to be installed. You are in the state right now where you zones are out of sync with the global zone. This happens because pkg image-update does not yet update all of the zones when you update the global zone. We' working on that for the next release. You should be able to just detach the zones and then attach -u them again which will do the update of the zone automatically. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Capped memory for zone
Ketan wrote: whats the difference between setting zone capped-memory from zoncfg and setting rctl: name: zone.max-locked-memory .. if changed the zone.max-locked-memory with prctl it does not change in rcapstat .. but if change with rcapadm it reflects in rcapstat o/p The capped-memory resource allows you to set three different properties; physical, swap and locked. These three caps are enforced in different ways. The swap and locked caps are rctls in the kernel so these are hard limits. The physical limit is a soft cap enforced by rcapd running in the global zone. This is why you are seeing different behavior when you talk to the underlying subsystems directly vs. using zonecfg. When you use zonecfg, zones manages all of these stuff for you behind the scenes. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] solaris10 brand source code
I have posted the current source for the solaris10 brand on the project page at: http://www.opensolaris.org/os/project/s10brand/ This source is synced to ONNV b116. Its a compressed tar archive which you can unpack into an ONNV workspace which has been synced to b116. If anyone has any problems with getting their workspace set up or built, let me know. We're syncing our project workspace up to ON on their schedule so I'll be posting updated code every two weeks. I'm assuming people are most interested in building this so that they can play around with it. The current download is quite small, less than 100k. If there is any interest, I could post pre-built SVr4 pkgs so that people don't have to go through the trouble of maintaining and building their own ON workspace. If anyone is actually interested in participating more fully in the project with actual development contributions, let me know privately so we can work together on coordinating the work and getting it integrated into the tree. You would also need a signed contributor agreement to do this. Let me know if there are any questions or comments. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pkg install AMP in a sparse zone
Devin Ceartas wrote: Yikes! Seriously, no sparse zones? That wasn't in the Bible book I don't think. This is a pretty big deal! Is this list the best place to follow to learn such things? Yes, this has been discussed on this alias in the past. Also, Dan Price blogged about this here: http://blogs.sun.com/dp/date/20080512 This is described in the OpenSolaris Bible on p. 732, second to last paragraph. Since software management for zones on OpenSolaris is still evolving, it would be helpful for us if you could describe what problems the lack of a sparse zone will cause you. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pkg install AMP in a sparse zone
gz wrote: Double Yiekes!!. All my customers use an SOE of sparce zones (With Solaris 10 of course) so if that is really the case it will be a problem for them to migrate to OpenSolaris if/when that becomes neccessary. Something like this could have serious concequences down the track and should be communicated to the field/customers real quick. This has been discussed here previously. What problems will it cause for your customers migration? The fact that there is no upgrade from S10 to OpenSolaris seems like it would be a bigger issue. We're looking at the solaris10 brand as one tool to aid with this, but of course those zones would also have to be whole-root. The solaris10 brand project does include support for p2v and v2v tools. Since the content of the next release of Solaris is nowhere near being finalized yet, it is premature to communicate anything to customers about what the final release will look like. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pkg install AMP in a sparse zone
Hung-Sheng Tsao wrote: guess is that the memory sharing benefits of sparse zones are relatively small in most cases. May be I am wrong here, it seems that with sparse zone and single binary for all zone there must be same memory sharing!!! I don't know what single binary you are talking about. If all of the sparse zones are running the same applications then there would sharing. If they are running different applications or even running common apps at different times, then there would be little sharing. The core OS daemons would be shared, but that isn't going to account for much. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pkg install AMP in a sparse zone
Steffen Weiberle wrote: I have been doing all on Solaris next testing using Nevada, as all the tools I know work, and my understanding of installation and configuration applies to that as well as Solaris 10. Now I am playing with 2009.06 and some 'simple' things don't work as expected. I couldn't copy a sysidcfg file into zonepath/root/etc/ as that is no longer mounted after an install. The 'correct' operation is to detach a newly created zone, copy the file in, and attach. I was surprised how long the attach took! Scripts will definitely have to change. This is tracked as: 3979 zone fs only available from Global zone, when zone is booted You can ready the zone to workaround this for now. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pkg install AMP in a sparse zone
Christine Tran wrote: On Mon, May 18, 2009 at 9:59 AM, Jerry Jelinek gerald.jeli...@sun.com wrote: Thanks for the write-up. It is helpful for us to know what peoples concerns are for the sparse vs. whole root configurations. Our application make and destroy zones as needed. We've built up a set of tools to create, clone, and tear down zones. We're concerned more with how fast we can build one and move one, than in how much memory we're saving by sharing in-memory footprints. (At one time this was a point to be made but I don't think anyone ever made any measurement, I could be wrong.) To make ipkg zones, we'd have to have access to a repository or maintain a local one (to date I don't think anyone's done this yet, right? The default repo is still at a opensolaris.org space.) Machines behind air gaps may never be able to run OS, and if they do, we'd have a harder time making zones on the fly for them. 1. ipkg zones take longer to build 2. and require an internet connection Installing from a repo is orthogonal to the sparse vs. whole root discussion. That is tracked as: 1947 Offline zone creation is impossible If you want to install zones quickly you should be using cloning. That would also solve the offline issue. I don't think anyone ever thought installing a zone with SVr4 pkging was fast. It is important to remember that zones on OpenSolaris are a work in progress. What we have now is not what the final implementation will look like. For sparse zones, that is totally up to IPS. If IPS doesn't support sparse zones, then we won't be able to do that on OpenSolaris. However, there are many different reasons to use sparse zones, memory, disk space, security, etc., and we can probably solve all of those needs using other techniques. For example ZFS deduplication will bring a lot to whole-root zones on OpenSolaris. So, it is important for us to know what the real need is, and not simply fixate on sparse zones as the only solution. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pkg install AMP in a sparse zone
Steffen Weiberle wrote: I originally could only imagine the reason for not doing the mounts when the zone is not booted is to avoid a huge set of ZFS mounts for zones that are not running. However, I see three ZFS file systems for a zone, and this is without any Live Upgrade (beadm) operation. Two are legacy, so visible via 'zfs', yet not mounted. Now I guess this keeps the Solaris mount behavior similar to that in S10, only shows mounts for running zones (since zonepaths typically were within an existing UFS file system, and thus mountpoint). The reason that the zone's datasets are not mounted when the zone is halted is that these mounts are currently managed by the brand hooks. The eventual goal is to enable software management within the zone, just as you have in the global zone. That is, beadm should work, as should 'pkg image-update'. Thus, we must determine the correct dataset to mount at zone boot time. We do not currently have a brand hook to enable us mount the datasets when the system boots. Thus, we have to wait until the zone is first booted. We could leave the dataset mounted after you halt the zone but that might not be the same dataset that will be mounted the next time the zone boots. We need to add a bit more brand infrastructure for this plus improve the existing hooks to make this cleaner. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Upgrading solaris10 branded zones
I've been spending some time researching ideas for how we could upgrade Solaris 10 once its installed in a solaris10 branded zone on S.next. We won't need this capability until S10u9 is released, but I want to make sure we do whatever we need to do now in order to enable this for the future. I have two possibilities in mind. Each of these is project level in its own right, so I assume we will only actually be able to do one of the options. 1) Make live-upgrade work inside the solaris10 branded zone I've been looking at the LU code to try to see what might be involved. There is no way we can emulate for this. We would have to do a project in the S10u9 LU code to make it solaris10 branded zone aware and enhance the code to make it work for upgrade inside the zone. There are various issues, such as ZFS pool awareness, mnttab parsing, file system mounting, grub awareness, etc. which would have to be coded around or changed. To enable this for the future I think we would have to set up the solaris10 zone now using a ZFS root dataset model similar to what we're doing today with the ipkg brand on OpenSolaris. Pros: a) The zone sysadmin would be in control of the upgrade. b) The user would be using a S10 tool to upgrade the zone (even though that tool will have been enhanced to be solaris10 zone aware). c) The zone admin could use LU ABEs to apply patches to their zone. Cons: a) We don't know this code. b) This is S10-only code that would have be enhanced. c) This is closed source so no community involvement. d) This is complex, legacy code which is a hairball. e) This code is fragile and there might be strong pushback for changing it further in S10. f) There is no re-use or other benefit to this work. 2) Enhance the zones update on attach code to do a real upgrade The idea here is that we improve the 'update on attach' code so it can use a Solaris 10 CD image as the source of the pkgs instead of the global zone. We would also enhance the code so it uses the full pkg list from the CD image instead of just the system software pkgs that have to be updated to sync the zone. The global zone admin would run this new code to upgrade specific solaris10 branded zones. They could either upgrade the zone in place or clone the zone and upgrade the clone, providing similar functionality to LU. Pros: a) I think this would be a simpler project. b) This code could be easily re-used to provide a true single zone upgrade on attach feature for a S10 native zone backport - lots of people want that. c) We know this code. d) This code is open source and readily re-usable. Cons: a) Upgrade would be done by the global zone admin, not the zone admin, so the zone admin is no longer the one in control. b) Because LU wouldn't work this might cause a perception of incompatibility between the solaris10 branded zone and a bare metal system. c) This doesn't solve the problem of using LU to apply patches to an ABE within the zone. Please send me any comments on preferences for one solution or the other, as well as any other thoughts on this topic. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Ellard Roush wrote: Hi Jerry, This document provides a lot of useful information. The section solaris10 Brand: What's Not Emulated you repeat some old information that is no longer correct. One point to note is that TX will continue to be incompatible with branded zones. That statement probably dates to the time when the lx brand was the only branded zone other than native. Solaris Trusted Extensions (TX) does not support lx and so it was correct at that time to state that TX does not support branded zones. The BrandZ framework now supports multiple kinds of zones, including the native brand zone. The BrandZ framework provides a powerful mechanism for tailoring the behavior of a zone. The Sun Cluster organization has taken the native brand zone and used the BrandZ framework to add callbacks for notifying Sun Cluster software about various zone changes. This cluster brand zone is a branded zone, but is really a native zone with cluster hooks. Our goal is make this cluster brand zone behave as much as possible just like the native brand zone. We have recently been successful in getting Sun Cluster to work with TX using the cluster brand zone. The Zone Cluster provides a cluster-wide security container. :) So please revise your statement about TX not being able to work with zones other than the native zone. Ellard, TX is incompatible with branded zones which actually implement emulation with a brand module. The cluster brand and the labeled brand do not do this, so since those brands only use the simple user-level hooks, they can co-exist. Brands such as lx, solaris8, solaris9 or solaris10 which need emulation support within the kernel cannot co-exist with TX. See the brand_register_zone() function in usr/src/uts/common/os/brand.c. I'll add some text to clarify this. Thanks for looking it over, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] S10 brand spec.
Enclosed is a first draft of a spec. for the S10 brand which we plan to submit for a PSARC inception review. Please send us any comments or questions. Thanks, Jerry --- S10C: A Solaris 10 Branded Zone for Solaris.Next Gerald Jelinek, Jordan Vaughan Solaris Virtualization Technologies [A note on terminology: This document uses the terms Solaris 10 and Solaris.Next very frequently. As such, the abbreviations S10 and S.next respectively are used interchangeably with the longer forms. The term virtualization is abbreviated as V12N.] Part 1: Introduction Each new minor release of Solaris brings with it the well known problems of slow user adoption, slow ISV support and concerns about compatibility. The compatibility concerns will be more pronounced with the release of S.next since it's anticipated that there will be greater than normal user-visible changes (e.g. the packaging system, etc.). Fortunately, since the last minor release of Solaris (Solaris 10), V12N techniques have become widespread and V12N can be used as a solution to ease the transition to the new version of Solaris. Zones[1] combined with a brand[2] are particularly well suited for this task since the host system is actually running S.next, whereas this is not necessarily the case with other V12N solutions. In addition, zones are usable on any system which runs S.next, which is also not the case with other V12N alternatives. We already have a proven track record delivering this sort of zones/brand based solution to enable running earlier versions of Solaris on S10 [3, 4], so in one sense this case breaks little new ground. However, the earlier 'solaris8' and 'solaris9' brands were used to host releases that are very static as compared to hosting a zone running S10. In addition, S.next can be expected to continue to change rapidly for the forseeable future. Given this, a 'solaris10' brand for S.next poses additional challenges for projects on both the S10 and S.next sides of the system. Many of these challenges are outside of the scope of an architectural review and include developer education, testing and procedural changes. However, the existence of this brand could potentially impact future projects in various ways and at a minimum will require ARC consideration for future reviews. The existence of this brand can be seen as a potential tax on all projects which work on both sides of the user/kernel boundary for both S10 and S.next. The benefits of the brand are as follows: For customers: - Provides a solution to cope with compatibility differences between S10 and S.next - Protects investment in S10 infrastructure, training, and internal support - Minimize the cost of consolidating Solaris 10 systems - Enables deployment of new technologies in S.next (e.g., crossbow) while still running applications on S10, thereby limiting risk to production environment - Avoids or delays required application recertification For Sun: - S.next is adopted sooner - Provide a Solaris compatibility environment for S.next - Sun is a solution provider easing the burden of getting to S.next - Provide cross-platform virtualization solution for S.next across all hardware (it is the only V12N solution on M-Series) This has been identified as a required feature for S.next. === Project Overview === As with the earlier 'solaris8' and 'solaris9' brands, this project delivers the following: - A Branded Container which emulates Solaris 10's user environment, based on the BrandZ infrastructure provided with zones. This brand is called 'solaris10'. Only Solaris 10u8 and beyond will be supported and tested in the zone. - A mechanism for archiving existing Solaris 10 systems and for redeploying those archives into the branded zone. This process is referred to as p2v and uses the same techniques as the 'solaris8' and 'solaris9' brands. In addition, the following additional capabilities will be provided as compared to the 'solaris8' and 'solaris9' brands. - This brand will be supported on all hardware architectures that run S.next (sun4v, sun4u and x86). The specific platforms, particularly sun4u, will be the same as are certified for S.next. - A virtual to virtual or v2v mechanism for archiving existing Solaris 10 native zones and for redeploying those archives into the branded zone on S.next will be provided. The process will be very similar to the existing zone migration [5] feature except that the zone's brand will be changed as part of the process. In addition, if the zone is sparse on S10 it must be converted to a whole-root zone during the migration. Part 2: solaris10 Brand The solaris10 brand is conceptually similar to the existing solaris8 and solaris9 brands and builds
Re: [zones-discuss] S10 brand spec.
Hernan Saltiel wrote: Hi! Will there be an adoption toolkit, to let the people use the S10 brand while testing it, and starting the migration process? I'm not sure I understand the question. Are you asking if the source code will be available before S.next is released? If so, then yes, we're running this as an open project and our plan is to get the current code that is under development posted on the project page within the next month or so. We have to finish an internal process review first, before we can open the code we've already written. After the code is posted, we'll be keeping it updated as we work on it. Once the code is available, you'll be able to build it and use the brand on OpenSolaris to try it out. If I misunderstood your question, please let me know. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Hernan Saltiel wrote: No, I'm talking about the Solaris migration toolkit, available in the past to certify pre-Solaris 10 binaries against the new versions. They were a couple of Perl scripts (solcat, for example). They were a binary interface certification set of scripts. They were a good point to start thinking in a migration. Thanks for the clarification. We are planning to build a tool which we're calling the 'preflight checker'. The idea is that you could use the tool on your S10 system and it would evaluate things to tell you what issues it sees that might have an impact on moving that system image into a solaris10 branded zone on S.next. The preflight checker isn't part of this initial project proposal but would be a small add-on project coming later. The tool might do some level of binary analysis but it would also look at other aspects of the system configuration as a whole. For example, it would check if you have zones, add-on kernel modules, etc. We haven't started to scope this tool out yet. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Menno Lageman wrote: Thanks, that clears it up. Adding some text at the start of the Versioning section that newer versions of the brand will provide compatibility for older versions of the brand would help I think. Thanks, I'll add that clarification. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Mike Gerdts wrote: Any thoughts on supporting live upgrade? That is, I would like live upgrade within the branded zone to work as it does for a S10 global zone. I don't care about it from the upgrade standpoint, but it is a very helpful tool for patching. Having a zfs zonepath is an acceptable prerequisite. Mike, We know that we need to come up with some sort of solution for being able to upgrade a solaris10-branded zone. We have this on our list of things to look at but we haven't started on that yet. I don't know if we'll try to make live-upgrade work inside a branded zone or if we'll try something else. Making live-upgrade work would probably be hard but until we get into it, we don't know how hard. It might be that we do something else since its already easy to clone a zone. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Mike Gerdts wrote: I suspect that making live upgrade work within a zone would be significantly easier if ZFS was a prerequisite. It looks as though the ipkg brand already has support for mounting the appropriate dataset on boot and attach. Delegated datasets can be snapshotted and cloned within the non-global zone. It seems as though the only missing bits (without having read the LU code) are: - Live Upgrade shouldn't try to read or update OBP through PICL or otherwise - The brand needs to trick live upgrade into thinking that it is in the global zone I don't care so much if Live Upgrade or something else is chosen, I just see the lack of a live upgrade work-alike as a potential blocker to adoption. Mike, Yes, we agree that some sort of upgrade solution is a requirement. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones in opensolaris (os200811) differs from zones in solaris 10?
solarg wrote: thanks for all reply, but can you suggest a way to lower the space occupied by a such zone? the problem with os2008.11 is that everything is installed at initial setup, but having zones occupying more than 5Gb is very bad! This is incorrect. Only a small subset of packages are installed. I just did a fresh zone install. It only took 144 MB and there are the only 58 packages installed. If you've added extra packages you don't need, removing them will reduce the size of the zone. Likewise with zfs snapshots or clones you're not using. We're looking at sparse zones or other alternatives for the future, but since IPS does not currently support that concept, it cannot be used on OpenSolaris at this point. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones in opensolaris (os200811) differs from zones in solaris 10?
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. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris10 brand project proposal
Dan Price wrote: Belatedly, a big +1. Jerry, if you have not already, I can take this to the OGB for creation. Thanks Dan. I think we have enough votes now. I will see about getting this set up this week. If I need a hand, I'll let you know. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] solaris10 brand project proposal
Robert, Robert Milkowski wrote: +1 !!! Thanks for voting for this. Do you plan to provide S10 brand zone on top of Solaris 10 too? This would much simplify patching and reduce downtimes when S10 zones are being used under Sun Cluster. Actually when it comes to patching S8/S9 branded zones are currently easier to deal with than native zones... IIRC I saw a project proposal to address it - I'm not sure if it is a separate project or is it under this project or if I have imagined it... There is currently no plan for implementing this in s10. However, there are a couple of other projects which should make a big improvement in patching zones on s10. One is: PSARC/2008/644 Parallel Patching of Zones which was not an open case and the other is: http://arc.opensolaris.org/caselog/PSARC/2009/173 PSARC/2009/173 Fasttrack for turbo-charging SVr4 package install. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] solaris10 brand project proposal
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
Re: [zones-discuss] solaris10 brand project proposal
Ben Rockwood wrote: Sounds like a necessary brand and a good idea. I admit, I'm curious what needs to be emulated? I would think that Solaris 10 zones would work just fine under OpenSolaris as native branded zones. Ben, There are a few differences in the kernel between s10 and opensolaris. Right now we're emulating 10 system calls and only running shared stack. We haven't yet started to scope the work for exclusive stack but with crossbow in opensolaris, that will be a big area of emulation. Once the project goes up, people can see the exact syscalls we've emulated so far. Plus, since S10 and opensolaris are under active development, the kernels could continue to diverge and we might need to emulate more syscalls over time. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] IPKG Brand for S10/SX:CE
Ben Rockwood wrote: One issue I did smack into that I don't fully understand yet is the syseventd service failing within the zone. I'm still trying to hash out how to solve that. Ben, The sysevent service should not run in the ngz. This is delivered in a hollow pkg with svr4 pkging. You might take a look at my p2v webrev for opensolaris. http://cr.opensolaris.org/~gjelinek/webrev.p2v/ In the p2v script there is a fix_smf() function which looks at the IPS pkgs to determine which SMF services should be deleted inside the zone. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
