This fast-track covers the SMF-related changes for dom0. This is a final draft,
so any comments by the end of the week please...
Man pages are attached.
thanks
john
SMF services for Xen
1. Introduction
This case introduces the SMF services used by a Solaris-based domain 0 when
running on Xen, or a Xen-compatible hypervisor. All of these services only
run on domain 0 when booted under Xen virtualisation.
A patch binding is requested.
2. Platform profiles
As booting under Xen leaves the platform as i86pc (uname -m), and due to
the issues described in
6447260 issues with platform_i86xen.xml profile,
we cannot use a platform profile to enable these services. Instead, these
services are delivered as disabled, and enabled via the contracted
/var/lib/profile/upgrade method on next boot. When not booting under Xen
(uname -i != "i86xpv"), the services will temporarily disable
themselves
and log a suitable message in the relevant log file under /var/svc/log/.
The first service method to run will disable all three services in this
case. When a better solution to this problem appears, the services will be
modified to use it.
Note that these services will only run as a result of an explicit user
action, namely booting Solaris under Xen as a domain 0. In general, there
is no reason to run as a domain 0 without making use of the control tools.
All the services are standard contract services.
3. Xen Store Daemon
/usr/lib/xenstored is a simple daemon implementing the database of
configuration parameters for each virtual instance running, and has the
FMRI:
svc:/system/xctl/store:default.
Due to significant Xen shortcomings, the daemon is not currently safely
restartable; if it fails or is otherwise stopped, the Xen control tools
as administered via xm will not work. See:
6447387 can''t restart xenstored
It is dependent upon svc:/system/filesystem/local.
4. Xen Console Daemon
/usr/lib/xenconsoled is also simple and acts as a virtual console server
for each domain (excepting domain 0). It serves clients which connect via
''xm console <domain>''. Its FMRI is:
svc:/system/xctl/console:default
It is dependent upon svc:/system/xctl/xend:default.
5. Xen Control Daemon
svc:/system/xctl/xend:default
''xend'' is the main centerpiece of the Xen control tools.
It is used to keep
track of domains the machine is running, and lives in /usr/lib/xend.
It is dependent upon svc:/system/xctl/store.
On other platforms, xend is configured via a (very) free-form file placed
in /etc/xen/xend-config.sxp. Due to the difficulty in machine-reading the
contents of this file for CAS scripts for upgrade, this case proposes to
implement the configuration parameters as SMF properties from the outset.
The risk in deviating from the standard configuration method found on other
platforms is expected to be outweighed by the improved configuration
facilities of SMF. The xend-config.sxp contains a number of configuration
parameters that we do not represent as configurable at all on Solaris.
Some of them constitute security risks, such as the HTTP server, and others
do not seem to be useful at this time, such as the location of the log
file. The names chosen reflect those in the xend-config.sxp file for
simpler implementation and familiarity purposes. Thus, we are providing
the following properties currently, which are all in the xend''s
services
''config'' property group:
enable-dump (default: true)
Whether xend should generate domain core dumps if a domain under Xen
control crashes.
xend-unix-server (default: true)
Whether xend should create UNIX sockets for communication with xend
over HTTP. By default, xend provides an XML-RPC socket in
/var/run/xend/xmlrpc.sock for communication. This option enables the
creation of two UNIX sockets:
/var/lib/xend/xend-socket
/var/lib/xend/relocation-socket
the former of which is for communication with xend, and the latter is
used for the domain migration feature of Xen. Note that both of these
interfaces are already considered as legacy by the community, although
they are used by some external software such as libvirt; thus, for
now, they should be provided (and in the unfortunate locations above).
It is expected that all software will move to the new XML-RPC
interface, work on which is underway.
xend-relocation-server (default: true)
Whether xend should listen on port 8002 for domain migration requests.
xend-relocation-hosts-allow (default ''^localhost$'')
A space-separated list of regular expressions. Any host matching any
one of the regexps listed will be allowed to connect for domain
migration if xend-relocation-server is enabled.
dom0-min-mem (default: 196, units Mb)
The minimum amount of memory reserved to the control domain, dom0. When
starting domains, if there is not enough free memory available to the
hypervisor to construct the domain, xend will ask dom0 to release
memory it owns. This value is the limit on the amount of memory beyond
which xend will request memory from dom0.
dom0-cpus (default: 0)
The number of physical CPUs dom0 is using. A value of 0 defaults to
"use all physical CPUs". When xend starts, this value controls
whether
dom0 runs on all physical CPUs, or a subset (starting from CPU0 up
to the value specified). This option can be used for physical
partitioning of CPUs between the control domain and other domains. Note
that this option does not change how many virtual CPUs dom0 has, which
by default is equal to the number of physical CPUs (where physical
corresponds with the Solaris kernel''s notion of a cpu_t).
6. Security issues
Currently, as on other platforms, all of these daemons run as root with
full privileges. Further work is underway to utilise least privilege and
other Solaris security technologies to improve this situation.
Additionally, the community is working on authentication schemes for
access to the control tools as part of the ''xend API''
work. We intend to
leverage this work as we track upstream development.
7. Interface table
It is unclear that the interfaces provided in this document will remain
stable as upstream community development continues. In particular,
forthcoming releases are providing a radical new base for administrative
remove access to the control tools. As a result, we feel that the
interfaces described here are best represented by a classification of
Volatile:
svc:/system/xctl/store:default Volatile
svc:/system/xctl/console:default Volatile
svc:/system/xctl/xend:default Volatile
svc:/system/xctl/xend:default (properties) Volatile
/var/lib/xend/xend-socket Obsolete Volatile
/var/lib/xend/xend-socket (wire protocol) Obsolete Volatile
/var/lib/xend/relocation-socket Obsolete Volatile
/var/lib/xend/relocation-socket (wire protocol) Obsolete Volatile
8. Man pages
Man pages for xend, xenstored, and xenconsoled can be found in the
materials.
9. References
PSARC/2006/260 Solaris on Xen