Re: [zones-discuss] Branded zones and external hardware
On 08/05/10 07:03, joerg.schill...@fokus.fraunhofer.de wrote: "Frank Batschulat (Home)" 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 06/01/10 15:12, Ian Collins wrote: Done: https://defect.opensolaris.org/bz/show_bug.cgi?id=16126 Thanks for filing this, 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/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] 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] impossible to attach migrated zone to a new server
On 05/19/10 14:08, Philippe Bürgisser wrote:
Hello,
thank your for your answer, I updated my initial message, myzone corresponds to
"proxiproduits" but I wanted to change the real name for the forum, my
mistake...
Anyway, after running the command zoneadm -z myzone attach -u, I get the same
error message...
When using OpenSolaris and moving the zone
from one system to the other by hand you have
to be really knowledgeable about manually
creating the zfs datasets properly or else things
won't work right. In order to make this work better
without requiring so much work, we've added a
new option to the attach subcommand. This is
the -a option which allows you to pass in the path
to your archive. Using this you can do something
like the following:
# zoneadm -z myzone attach -a {path}/myzone.tar -u
This will create all of the necessary datasets, unpack
the archive into the zonepath root, then update the
image as needed. If you want to try this you should
clean up your existing zonepath and let zoneadm just
do all of the work.
This still doesn't work very well when you also want
to use the detached zone on the zonecfg create
step, as you did. There is more work we really need
to do here to make all of this seamless. If you want
to manually do the steps to set up the zonepath then
you need to understand how the zfs datasets are
setup with one dataset on the zonepath and another
on the zonepath/root. This is pretty error prone and
probably not something most people will want to do,
which is why we added the -a option.
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=en&a=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 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 Jelinek 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] 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] 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] 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 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: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 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] 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 11:32, Frank Batschulat (Home) wrote: Thanks Jerry, that is indeed a valid concern, I changed it to be: PAGER /usr/bin/nonsense does not exist (No such file or directory). 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] 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] 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 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] 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] 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] Problem creating a new zone in svn_130
On 01/20/10 15:01, Johan Hedin wrote: Hi all I'm trying to create a new zone in OpenSolaris svn_130. r...@dom0:~# zonecfg -z test info zonename: test zonepath: /internal/zone/test brand: ipkg autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: net: address: 192.168.0.30/24 physical: nge0 defrouter: 192.168.0.254 r...@dom0:~# zoneadm -z test install A ZFS file system has been created for this zone. ERROR: Unable to create the zone's ZFS dataset. r...@dom0:~# zfs list | grep test internal/zone/test 42K 222G21K /internal/zone/test internal/zone/test/ROOT 21K 222G21K legacy Am I doing anything obviously wrong, or is this a bug? Where did the internal/zone/test and internal/zone/test/ROOT datasets come from? Where they there before you tried to install the zone or left over when the install failed? It looks like your datasets aren't set up the way zones needs them to be. You need internal/zone to be a dataset so that zones can automatically create the datasets it needs underneath there. You should get rid of the internal/zone/test and internal/zone/test/ROOT datasets since zones will create those in the proper manner. Thanks, 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] 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
Ed, Thanks for reviewing this, my responses are inline. On 01/15/10 19:26, Edward Pilatowicz wrote: On Thu, Jan 14, 2010 at 09:18:20AM -0700, Jerry Jelinek wrote: I need a code review for my proposed fix for: 6887823 brandz on x86 should ignore %gs and simplify brand hooks There is a webrev at: http://cr.opensolaris.org/~gjelinek/webrev.6887823/ This simplifies some of the handling for the %gs register, cleans up the interfaces with the brand modules, and consolidates common code into a single file. Although the webrev looks large, most of this is because of moving the common code. hey jerry, looks good. a few comments below. ed -- usr/src/uts/i86pc/ml/syscall_asm.s - so i think the following comment is true for lcall and int syscalls on 32-bit kernels: * -- * | user's %ss | *|| user's %esp| *|| EFLAGS register| *|| user's %cs | *|| user's %eip (user return address) | *|| 'scratch space'| but what about sysenter syscalls? none of that stuff will be on the stack. (that's why BRAND_CALLBACK used to explicitly push the user return address onto the stack.) have you tested with sysenter syscalls on 32-bit kernels? I haven't really changed this. If you look at the original code in syscall_asm.s, all it was doing was re-pushing a value that was already on the stack. This is line 152 in the original code in syscall_asm.s. The reason this works is that the sysenter callback doesn't use the data from the stack since the return address is in the %edx register (see the comment on the callback in s10_brand_asm.s or sn1_brand_asm.s). The SYSCALL_EMUL macro expects the return address to be in a register, not on the stack. -- usr/src/uts/intel/brand/common/brand_asm.h - could you create this file by doing an hg cp of sn1_brand_asm.h or s10_brand_asm.h? (it preserves the history and also makes it easy to see changes to the defines.) Done. - this doesn't seem right: #ifndef _SYS_BRAND_ASM_H the SYS_ prefix is normally used by header files in /sys/. for this file you should probably have: #ifndef _BRAND_ASM_H #ifndef _COMMON_BRAND_ASM_H Changed. - this file should probably #include the files which define macros that it uses. for example, you should probably include: #include i'm sure there are others as well. Changed. -- usr/src/uts/intel/brand/*/*_brand_asm.s - you've removed all the comments that explain how the stack frame looks and what the assumptions are when we enter the different handlers. i realize this is all documented in brand_asm.h now, but now folks don't know how to map each of the handlers to their running conditions. it'd be nice if there was a comment for each handler pointing people to that the correct comments that apply to each handler. perhaps it would make sense to add some "tokens" to the comments in brand_asm.h like: 32-BIT INTERPOSITION STACK 32-BIT LCALL/INT STACK 64-BIT INTERPOSITION STACK 64-BIT LCALL/INT STACK and then in the comments for each brand callback you could refer the reader to the appropriate tokens in brand_asm.h. I added this. -- usr/src/uts/intel/brand/lx/lx_brand_asm.s - in lx_brand_int80_callback() you have: * See the comment on CALC_TABLE_ADDR in brand_asm.h for an but this function never uses CALC_TABLE_ADDR. it still does the offset calculation manually: shlq$4, %rax i think you could clean this up by changing CHECK_FOR_HANDLER and CALC_TABLE_ADDR in brand_asm.h to be de CHECK_FOR_HANDLER(scr, handler) ... cmp $0, handler(scr); /* check handler */ and: CALC_TABLE_ADDR(scr, handler) ... mov handler(scr), scr; /* get p_brand_data->handler */ \ then you also don't need this at the top of every brand: #define USP_HANDLER ... and you can use CALC_TABLE_ADDR for jump table calculations in the lx brand. This is a good idea, I rewrote things along these lines. There is a new webrev at: http://cr.opensolaris.org/~gjelinek/webrev.6887823/ Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] zones code review
I need a code review for my proposed fix for: 6887823 brandz on x86 should ignore %gs and simplify brand hooks There is a webrev at: http://cr.opensolaris.org/~gjelinek/webrev.6887823/ This simplifies some of the handling for the %gs register, cleans up the interfaces with the brand modules, and consolidates common code into a single file. Although the webrev looks large, most of this is because of moving the common code. Thanks, 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] 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: 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: 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] 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
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: 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] 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: # uname -a SunOS lab234 5.10 Generic_139555-08 sun4u sparc sun4u # pkginfo -l VRTSvxfs PKGINST: VRTSvxfs NAME: VERITAS File System CATEGORY: system,utilities ARCH: sparc VERSION: 5.0,REV=5.0A55_sol # fsck -F vxfs -o p /dev/rdsk/c1t14d0s0 /dev/rdsk/c1t14d0s0:file system is clean - log replay is not required here's the new webrev for your consideration: http://cr.opensolaris.org/~batschul/onnv-vplat/ Frank, Looks fine to me. 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] 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
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] cloning a zone from a snapshot
Günther Schmidt wrote: Hello, I'd like to create a clone from a specific snapshot using zoneadm, but this feature seems to be broken in OSOL 2009.06. Is there another way of doing this? This is bug: 5940 Cannot create clone of zone from snapshot To workaround this you can make a clone of your source zone without specifying a specific snapshot. This will cause a new snapshot to be created. 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
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,
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
[zones-discuss] zones code review
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. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
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 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] 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] 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] 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: 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] 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] "ERROR: no active dataset." w/ migration from Indiana snv_125 to Indiana snv_127
John D Groenveld wrote: In message <4b1403ff.6000...@sun.com>, Jordan Vaughan writes: If I remember correctly, zbe datasets' mountpoints should be set to "legacy". rpool/var/zones/oracle-1/ROOT/zbe's mountpoint isn't "legacy" on your snv_127 system. What was rpool/var/zones/oracle-1/ROOT/zbe's mountpoint property's value on the snv_125 system prior to the zfs send operation? Looks like the detach on the snv_125 host changes the mountpoint property: This is the expected behavior. # zoneadm -z foo boot zone 'foo': zone is already booted # zfs get mountpoint rpool/var/zones/foo/ROOT/zbe NAME PROPERTYVALUE SOURCE rpool/var/zones/foo/ROOT/zbe mountpoint legacy local # zoneadm -z foo halt # zoneadm -z foo detach # zfs get mountpoint rpool/var/zones/foo/ROOT/zbe NAME PROPERTYVALUESOURCE rpool/var/zones/foo/ROOT/zbe mountpoint /var/opt/zones/foo/root local Is the bug in snv_125's detach or snv_127's attach? There is no bug, detaching a zone changes the dataset so that it is accessible on the source system, since the dataset has not mounted unless the zone is running. The mount behavior has changed in b127 and the zone's dataset is always mounted now but detaching a zone will still update the dataset mountpoint. The work-around is to mount the zbe. The workaround for what? Thanks, 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
Re: [zones-discuss] solaris10 branded zone in b127
Trevor Pretty wrote: Jerry That link did not work for me, just takes me to the main page. This link works:- http://hub.opensolaris.org/bin/view/Community+Group+on/2009102201 Trevor, Thanks for posting a working link. The original was broken by the website transition which occurred this morning. 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
[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] review needed for scratch zone mount fix
Edward Pilatowicz wrote: so now i've got a fix for that breakage: http://cr.opensolaris.org/~edp/onnv-zmount/ 6889379 zoneadm mount fails on opensolaris Ed, This looks fine to me. 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
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: 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: > 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 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
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, 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 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] 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 cp"d from the sn1 files, we'll just see the deltas against the sn1 files (instead of having all these files show up as new). I've generated a new webrev using some improvements Ed made to webrev. This, combined with the use of 'hg copy', make the webrev much smaller and easier to review. I've uploaded the new webrev to: http://cr.opensolaris.org/~gjelinek/webrev.646/ Please get me any comments by the end of the week so that we have time to make the necessary changes and rerun the tests before we integrate. Thanks, Jerry ___ 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] 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] 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] 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] Ancestor filesystems writable by zone admin - by design?
Miles Benson wrote: Thanks for getting back. Anyway, I've done some more digging. It seems to be related to having delegated a dataset to a zone. I have two zones 'basezone' and 'paulzone'. Forget the fact that I used the example of basezone above for a moment. basezone has no delegated dataset and when you zlogin you can do r...@muttley:~# zlogin basezone [Connected to zone 'basezone' pts/2] Last login: Mon Sep 28 19:29:31 on pts/2 Sun Microsystems Inc. SunOS 5.11 snv_111bNovember 2008 r...@basezone:~# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 93.8G 2.57T 53.6K /tank tank/zones1.12G 2.57T 41.1K /tank/zones tank/zones/basezone314M 2.57T 37.5K /tank/zones/basezone tank/zones/basezone/ROOT 314M 2.57T 34.0K legacy tank/zones/basezone/ROOT/zbe 314M 2.57T 309M legacy r...@basezone:~# touch /tank/zones/foobar touch: cannot create /tank/zones/foobar: No such file or directory r...@basezone:~# so all's well and good. paulzone on the other hand was cloned from basezone and then I created a new filesystem /tank/zones/pauldata and delegated it: r...@muttley:~# zonecfg -z paulzone info zonename: paulzone zonepath: /tank/zones/paulzone brand: ipkg autoboot: true bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: net: address: 192.168.246.249/29 physical: e1000g0 defrouter: 192.168.246.254 dataset: name: tank/zones/pauldata r...@muttley:~# so if we zlogin to that zone... r...@muttley:~# zlogin paulzone [Connected to zone 'paulzone' pts/2] Last login: Mon Sep 28 19:30:10 on pts/2 Sun Microsystems Inc. SunOS 5.11 snv_111bNovember 2008 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 r...@oberon:~# touch /tank/zones/foobar r...@oberon:~# ls -l /tank/zones/foobar -rw-r--r-- 1 root root 0 Sep 28 19:38 /tank/zones/foobar r...@oberon:~# not so good. It looks like you are doing all of this in the nonglobal zone. You can certainly create files in any directory in the path /tank/zones/foobar within the zone, but that doesn't mean you are doing anything to the global zone. Within the global zone, can you see /tank/zones/foobar? Can you create files in the global zone in /tank/zones that are then visible within the nonglobal zone? I cannot. Thanks, 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] 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] 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
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 is corrupt pathname does not exist Installation of on zone partially failed. = SUNWgssc pkgadd: ERROR: source path is corrupt pathname does not exist Installation of on zone partially failed. = SUNWkrbr pkgadd: ERROR: source path is corrupt pathname does not exist Installation of on zone partially failed. = SUNWntpr pkgadd: ERROR: source path is corrupt pathname does not exist Installation of on zone partially failed. = SUNWppror pkgadd: ERROR: source path is corrupt pathname does not exist Installation of on zone partially failed = SUNWsacom pkgadd: ERROR: source path is corrupt pathname does not exist Installation of on zone 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] 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
[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] 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?
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
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] 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] s10 brand code review
Ed, Thanks for reviewing this. Edward Pilatowicz wrote: - you might want to add the crypto libraries to the list of libraries to watch for breakage. ;) Yep. :-) I'm also going to try to see if any of the other default devices that are inside of a zone might have had their ioctl params changes in any way. - to improve the readability of crypto_ioctl(), could you make a dedicated function or macro that just does translation between the s10 and nevada versions of crypto_get_function_list_t? Will do. - when you make the ioctl call, i see you can do a CT_TSET. in this scenario you only initialize native_param.fl_provider_id, and the rest of native_param is garbage. is that ok or should the rest of native_param be zeroed out? For CT_TSET that goes through the new ctfs_ioctl() function, not this new code for /dev/crypto. That function is the original code Jordan did which I just moved out into its own function for readability. Thanks again, 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] 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
[zones-discuss] s10brand code review
I need a code review for the sysinfo support for the s10 brand. There is a webrev at: http://cr.opensolaris.org/~gjelinek/webrev.sysinfo/ Thanks, 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] S10 brand spec.
Peter Memishian wrote: > Part 2: solaris10 Brand > > > The solaris10 brand is conceptually similar to the existing solaris8 > and solaris9 brands and builds directly on the BrandZ infrastructure > that was created to support the lx brand. Familiarity with BrandZ > and the solaris8 and solaris9 brands is assumed. > > At this time the design and development of the brand is only > supporting the shared stack [6] networking model in which the zone's > network is managed by the global zone. The exclusive stack model > is anticipated to require more complex solutions or emulation due > to the introduction of Crossbow [7] into S.next. The exclusive > stack issues will be resolved before commitment review. Jerry, As I've mentioned in the past to Dan, it's worth noting that Crossbow is not the only project that has significant impact here -- e.g., Clearview UV and Clearview IPMP (among other projects) also made significant changes to both kernel and userland that are presumed to be in lockstep. I suspect you will be safe with shared-stack, but exclusive stack will pose some significant challenges, and in some cases you may find the path of least resistance is to use the S11 userland binaries inside the S10 zone. Using the S11 binaries might be what we wind up doing for this. We haven't started to investigate the exclusive stack yet, so we don't know all of the issues. We do already have a mechanism for running binaries from the global zone and we do use that in some other cases already. One concern might be around 3rd party S10 apps that want to do networking stuff directly. I'm not sure how common that would be or what, if anything, would not work. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Upgrading solaris10 branded zones
Mike, Thanks for reviewing this. I have a few comments in-line. I trimmed the rest. Mike Gerdts wrote: * ZFS pool awareness Isn't it already zpool aware as of S10u6? Perhaps you mean that it needs to handle paths other than rpool/ROOT/ such as [[/arbitrary path]/]/root/ROOT/. Yes, thats the problem. There is a lot of code in LU that is attempting to look at and manipulate zpools for the PBE and ABE. There is no zpool available within the zone so all of the code that wants to discover zpools and manage datasets within those pools will need modification. * mnttab parsing Would mnttab parsing be better handled by providing reasonable paths in mnttab via the brand shim? Consider an ipkg branded zone that I have on a SXCE snv112 system (yes it is a bit of a hack). Thats a possibility although it has an impact on the security model for zones themselves. Since this was part of the original design and assumptions for what global zone data would be visible within the non-global zone, I think we'd have to be very careful to understand what would break or become less secure by changing that. * file system mounting I think this is greatly simplified if ZFS is listed as a prerequisite for live upgrade support. That is, I think all of the code is probably there. Its more complicated than that since LU wants to manage mounts for the PBE and ABE but some mounts are managed by the global zone on behalf of the non-global zone, so we would have to make LU handle that properly as well. * grub awareness Clearly grub is not a part of this, nor is /dev/openprom or the bootfs zpool property. Perhaps this goes back to file system mounting above. The ability to call zoneadmd from within the zone (e.g. /var/run/zoneadmd_) to set a zonecfg bootfs property would probably be good. If we model this on what we've already done for the ipkg brand then we could cope with this. Its just more changes to LU to make it do this. c) The zone admin could use LU ABEs to apply patches to their zone. If an option with (c) isn't offered, many will go off inventing their own mechanism to simulate live upgrade. Having a recommended manual process and a structure that supports it will probably save Sun and Solaris users lots of time and money. The issues I highlighted above are just the ones I saw from a quick look at the LU code. I don't know what other problems are there since no one on the zones team knows the LU code base. Clearly we can make LU work with enough changes to the code. Its just software. I tried to highlight the fact that this is going to be a more complex option with no other benefit. It might simply come down to a decision about how much resources and time we have to work on an upgrade solution. It is unlikely we could get any resources from the install team since they are already fully committed on the caiman project and since this is closed source, we can't get any help from the community. S10u7 just came out, I think you said that this is targeted to support S10u8, and it would be able to upgrade from S10u8 to S10u9. Will S10u10 ever exist? Will it see a lot of adoption before S10u9 exists? If it is only good for a maximum one time upgrade with several years of patching afterward, this option doesn't seem to be worth it. I have no idea how many S10 update releases there will be. I'm not sure anyone else would really know either at this point in time. The best I can say is that S10 updates will continue for the forseeable future. Clearly I am more in the make "Live Upgrade work" camp. If the zfs userland components can be made to work in the solaris9 brand, there's benefit for it as well. If LU weren't so problematic it would be the obvious thing to do. Unfortunately, because of the issues I tried highlight, its not clear. I don't know of any plan to backport ZFS to Solaris 9. If there was such a plan, it would be a separate project by a different team. I would say that this is highly unlikely to ever occur. Thanks again for looking this over, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Upgrading solaris10 branded zones
Enda O'Connor wrote: d) This is complex, legacy code which is a hairball. that is the mild way of putting it, this code is a tangle of scripts and some C code, it took a a lot of work to iron out the issues that the zones on zfs + sparc new boot features introduced in u6 prior to releasing u6, and some work after release as well. This code is hard to maintain as is, unfortunately. While this would probably be the best way to go, I feel that that pain might be unbearable for all involved. I'd suggest talking to Mark Musante to get his opinion of LU as he did a lot if not most of the zfs part of u6 LU integration. Thanks Enda. If we decide the LU path is the way to go, then I'll definitely talk to Mark. Thanks again, 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] pkg install AMP in a sparse zone
Peter Tribble wrote: The key advantage of using sparse-root is that there's only one OS to manage. With whole-root zones, and other heavier solutions, there's an extra OS image to manage with each virtual system. From an admin perspective, whole-root zones offer no real advantage over xen/vmware, and while I would (and do) run sparse-root zones extensively, I would run Xen or VMware rather than whole-root zones, as they have other capabilities you can leverage. I think this is incorrect. There is always only a single OS to manage with zones, sparse or whole-root. There is always only a single kernel in memory. In terms of the user-level software management, that has to be done in both the sparse and whole-root cases. The only difference is that some new bits don't have to be copied for sparse, but the pkg metadata must be maintained within the zones in all cases, along with at least a subset of files. There are also other admin advantages for zones over VMs. There is only one kernel sucking up memory. There is massive scalability on a system with zones vs. VMs. Apps run at full speed vs. the overhead of a hypervisor and virtual I/O. You have full observability across all zones using tools like DTrace. Of course VMs have advantages over zones too. It depends on what is important to you. 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
Re: [zones-discuss] pkg install AMP in a sparse zone
Christine Tran wrote: On Mon, May 18, 2009 at 9:59 AM, Jerry Jelinek 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 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 /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
