In a previous
blog
I talked about integration of Solaris Volume Manager (SVM) and
RCM. Proper integration of SVM with the other subsystems in Solaris
is one of the things I am particularly interested in.
Today I’d like to talk about some of the work I did to integrate
SVM with the new Service Management Facility (
SMF)
that was introduced in S10.
Previously SVM had a couple of RC scripts that would run when the
system booted, even if you had not configured SVM and were not using
any metadevices. There were also several SVM specific RPC daemons
that were enabled. One of the ideas behind SMF is that only the services
that are actually needed should be enabled. This speeds up
boot and makes for a cleaner system. Another thing is that not
all of the RPC daemons need to be enabled when using SVM. Different
daemons will be used based upon the way SVM is configured.
SMF allows us to clean this up and manage these services within the code
so that the proper services are enabled and disabled as you
reconfigure SVM.
The following is a list of the services used by SVM:
svc:/network/rpc/mdcomm
svc:/network/rpc/metamed
svc:/network/rpc/metamh
svc:/network/rpc/meta
svc:/system/metainit
svc:/system/mdmonitor
The system/mdmonitor, system/metainit and network/rpc/meta services are the
core services. These will be enabled when you create the first metadb.
Once you create your first diskset the network/rpc/metamed and
network/rpc/metamh services will be enabled. When you create your first
multi-node diskset the network/rpc/mdcomm service will also be enabled.
As you delete these portions of your configuration the corresponding
services will be disabled.
Integrating this coordination of SVM and SMF is easy since SMF offers
a full API which allows programs to monitor and reconfigure the services
they use. The primary functions used are smf_get_state, smf_enable_instance
and smf_disable_instance, all of which are documented on the
smf_enable_instance(3SCF))
man page. This could have all be done previously using various hacks to
rename scripts and edit configuration files in various ways but it is trivially
simple with SMF. Furthermore, the code can always tell when there is something
wrong with the services it depends on. Recently I integrated some new code
that will notify you whenever you check the status of SVM with one of the CLI commands (metastat,
metaset or metadb) and there is a problem with the SVM services. We have barely scratched the service
here but SMF lays a good foundation for enabling us to deliver a true
self-healing system.