Evan Layton

We've made some significant changes and improvements for this release of SNAP (Boot Environment management). I've outlined some of these changes and given some short descriptions.
- Creating a new BE will copy any grub menu customizations made to the original BE's grub entry
- Activating a BE now checks the grub version of the BE being activated and if it's newer than the current version it will run installgrub so that the new BE can boot properly. This fix was back published so that the workaround requiring running update_grub, to update from 2008.05, is no longer needed.
- Support for non-legacy mounted ZFS root. With the addition of ZFS boot we no longer have to set the mountpoint property to "legacy". Also the root dataset of the BE is now mounted readwire in the kernel on bootup.
- Better BE name validation - matches the naming conventions for naming a ZFS dataset with the exception that spaces are not allowed.
- Better error messages throughout beadm and the library.
- BE's now have a uuid which is set as a user property of the BE's root dataset. This is also used to help the zones code know which BE the zone dataset belongs to.
- beadm is now in it's own package (SUNWbeadm) to make it easier to back publish important fixes to earlier releases.

Numerous fixes to both beadm and libbe...
for example things like:
- beadm list now shows correct mountpoint of a mounted BE not just what is in the ZFS mountpont property.
- Improved/more readable beadm list output.
- Fixed beadm list output that was showing unbelievably large amounts of space used. (larger than the total size of the pool.)
etc...

Zones support...
We have added support for ipkg branded zones in this release of SNAP. This allows up to copy a zone, based on that zone in the originating BE, into a new BE when it's created and when a BE is destroyed so is the zone but only those parts of that zone which belonged to that BE. When an inactivate BE is mounted the zones belonging to that BE are also mounted giving us access to that zone for doing updates, etc. Basically all of the beadm functionality supports a BE that contains zones.

In the current structure of a global zone BE (This is the global Boot Environment) the root dataset looks something like
"rpool/ROOT/BE-1" and in keeping with that type of namespace the ipkg branded zones make use of a similar namespace.
For example zone1 would have a root dataset similar to the following:
rpool/zones/zone1/ROOT/zbe mounted at /zones/zone1/root for zone1 when BE-1 is activate and booted.

When a new global zone BE is created the zones that belong to it are also copied into the new BE.
For example if we have BE-1 which contains zone1 and we create BE-2 zone1 will be copied into BE-2. This is done by cloning the dataset for zone1.
For example zone1 in BE-2 would have a root dataset similar to the following:
rpool/zones/zone1/ROOT/zbe-1 mounted at /zones/zone1/root for zone1 when BE-2 is activate and booted.

The dataset for the zone uses information stored in user properties of the dataset to determine which BE the zone belongs to. If there are multiple zone root datasets for a zone that all belong to the same global zone BE a dataset property is used to determine which of these is the active or bootable dataset for that zone. Also because the BE identifier (uuid) is stored as part of the dataset it doesn't change across a rename therefore even when the BE has been renamed the zone will still know which zone root dataset belongs to which BE as well as the BE knowing which zone datasets belong to it.

This ability to have a zone with multiple root datasets for a global BE makes possible zone boot environments. In the near future the BE management tools (beadm/libbe) will be made to work inside a zone as well so that zone BE's can be managed within the zone.

Note: Currently only ipkg branded zones are supported and only on ZFS. Also as implied above beadm and the libraries under it are not supported within the zone itself.

Next on the list of upcoming items is the Sparc support work...
- The only area where SPARC and x86 differ (as far as SNAP) is in the boot menu handling. In x86 we have the grub menu to contend with but on SPARC for ZFS boot there is a simpler boot menu file. These are very similar but are in different locations. The entries in these files are also slightly different as is the boot process that uses these files. The changes to SNAP to support SPARC were simply making changes to the way we dealt with the different boot menu files. This work is done but is not part of the 2008.11 release.

Installing SXDE 9/07 on a TZ190N[Read More]

This is my first attempt at a blog and I didn't have a great deal to say about me so I figured I go with what I've been working on lately. As for a bit about me, up until recently I've been a member of the NFS group working on automounter improvements and more recently an NFSv4 referrals prototype which we tested at this years connectathon.

As part of the NFSv4 referrals work we saw a need to be able to resolve a host name to it's netbuf address. To do that I came up with the following design ideas:

As part of fs_locations, it is possible for the referring server to return ip addresses (IPv4 or IPv6) as well as FDQN for the referred-to server(s). However, in constructing the mounta arguments an ip address must be used to describe the server. So, if an FQDN was returned for the referred-to server(s), we need to first resolve it to an ip address. The functionality that determines if we have a host name or an ip adress in fs_locations will be the same as what is currently used in the automounter.

To be able to access the host indicated in fs_locations we need to be able to call up into user space to get a netbuf structure; this will do name to address resolution for names and will also handle locations expressed as dotted-quad numeric addresses. To do this we will create a new daemon that will be passed the locations information from the kernel through an upcall and will return the netbuf containing the server address as well as the knetconfig structure. This daemon will set up a door and it's door handle will be placed into the nfs per-zone global data structure through a call to nfssys. The door will have the function nfsref_doorfunc() associated with it. This function will in turn create the CLIENT and call get_nfs4ref_info which does the name to address resolution. In the kernel we'll pull the door handle from the global data structure, xdr encode the utf8 string containing the server name and pass that through the door up to the daemon. When the daemon receives this request nfsref_doorfunc is called and the utf8 string will be xdr decoded and passed to get_nfs4ref_info which then xdr encodes and passes back the netbuf and knetconfig structures.

The function get_nfs4ref_info and get_server_netinfo will be the entry points into a new library that contains the code that does the name resolution. The library functions that do this will be get_server_netinfo, get_netconfig_info and get_knconf. These will be static functions in the library and will be used by get_nfs4ref_info.

The automounter will be essentially the same with the exception that the address lookup calls and the portmap cache will be moved to the hostname to address resolution library. The current client creation from get_server_stuff() will be expected to be done outside of the library functions and the client will need to be passed in to the library calls. The function get_server_stuff() will be renamed to get_server_netinfo(), moved to the library and will retain the same functionality. However the call get_the_stuff() will be divided into two functions the first will be called get_netconfig_info and will comprise most of the current behavior from get_the_stuff(). The second function will be get_server_fh() and will remain in autod_nfs.c. This function will be the functionality associated with getting the server fh (type_of_stuff == SERVER_FH) and will comprise what is currently in get_the_stuff starting at line 2909 through 3083 in autod_nfs.c. The automounter will make use of this with the current call to get_server_stuff() but this will now be a wrapper for a call to the library call get_netconfig_info() followed by a local call to get_server_fh() giving us behavior similar to what is currently there. Also to be moved into the library is the call to get_knconf keeping it's current behavior that will give us the knconf structure to pass back from the upcall. The upcall will make use of the get_server_netinfo which will call get_netconf_info() and get_knconf().

New functions in the library:

fsl_info_t *get_nfs4ref_info(CLIENT *cl, char *hostname)  (called by the upcall)
netbuf *get_server_netinfo(
   CLIENT *cl,
   char *host,
   rpcprog_t prog,
   rpcprog_t vers,
   struct netconfig *nconf,
   ushort_t port,
   bool_t direct_to_server,
   enum clnt_stat *cstat); 

static netbuf *get_netconfig_info(
   CLIENT *cl,
   char *hostname,
   rpcprog_t prog,
   rpcprog_t vers,
   struct netconfig *nconf,
   ushort_t port,
   bool_t direct_to_server,
   enum clnt_stat *cstat)

New functions in autod_nfs.c:

get_server_fh(
   char *hostname,
   AUTH *ah,
   CLIENT *cl,
   rpcprog_t vers,
   struct snego_t *snego,
   mfs_snego_t *mfssnego,
   char *fspath,
   enum clnt_stat *cstat)

existing functions that will be moved from autod_nfs.c to the new library:

struct knetconfig *get_knconf(struct netconfig *);
get_cached_srv_addr()
portmap_cache_lookup()
portmap_cache_enter()

required from libnsl:

rpcb_getaddr()
setnetpath()
getnetpath()
endnetpath()
getnetconfigent()
netdir_getbyname()
netdir_options()
clnt_call()
authsys_create_default()

headers needed:

fcntl.h
sys/types.h
sys/stat.h
netconfig.h