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 '. 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-address (default: "127.0.0.1") Address which xend listens on for relocation requests. If blank or not present, all interfaces are used. 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. In addition, no RBAC authorizations are being proposed in this case for the service and property administration of these FMRIs at this point in time. As there is no support for delegated administration in the rest of the Xen control stack at this point in time, this would be at best an attractive nuisance. (That is, there's not much point in delegating control of xend's properties when starting a domain instance requires root anyway). When further work is complete, RBAC facilities for these FMRIs will be detailed in a future case. 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 remote 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