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] why not just bury zoneadm [-x nodataset] option ?
Hi Frank, I'd be happy with ditching -x nodataset and requiring that zonepaths be backed by ZFS datasets. Only lx-branded zones would be able to support the option but I don't know any reasons why someone wouldn't want his lx-branded zones to be backed by ZFS datasets. Is managing an additional dataset detrimental to filesystem performance? Ed might have reasons for not burying -x nodataset but I recall him stating that zones will be backed by ZFS datasets/zpools/zvols on remote storage devices. It's time for me to research ZFS internals... :) Jordan On 12/ 8/09 07:31 AM, 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... thanks! ___ zones-discuss mailing list zones-discuss@opensolaris.org
