Auto-starting Xen/xVM domains in OpenSolaris

Posted by peter on May 19, 2009

Normally, when using Red Hat’s tools (which like everyone else Sun has ripped off wholesale) this is exposed in virt-manager and virsh, but the versions that Sun has brought over from Redhat lag quite a bit behind upstream, so you have to dig in below the convenience tools. Shut down your guest, then use xm list -l to dump the xen config file. There’s a on_xend_start property in here- change it from ignore to start, then dump it back into xen with xm new -F .sxp.

All at once:

pfexec xm list -l  > guest.sxp
sed -i 's/on_xend_start ignore/on_xend_start start/' guest.sxp
pfexec xm new -F guest.sxp

..and you’ve got a domain that’ll auto-start when xend is brought up, which is pretty much what I usually want.

making a manifest for SMF 1

Posted by peter on October 22, 2008

Sun is an incredibly frustrating company. A number of the new features introduced in Solaris 10 are very excellent, but I find all the Solaris userland a huge shitpile compared to my familiar GNU tools. Furthermore, the documentation for the aforementioned excellent features is pretty lacking at times, meaning a lazy dude like me gets little use out of them. However, I just finally stumbled into SMF, and I am now a fan.

I wanted to move a few of the programs I run into SMF, one of the aforementioned awesome features. ¬†SMF is Sun’s replacement init process, which takes a more active approach to services than the traditional “tell it to start and hope it does.” It, and all the other new init replacements borrow a good bit from djb’s daemontools, which everyone seems to be realizing, ten years later, is actually a good idea.

SMF provides two primary benefits over traditional init script methods, in my mind, the first of which is process supervision. Process supervision means that when your app crashes, you don’t have to rely on monitoring scripts (or other people) to notice it’s gone, SMF notices immediately and attempts to restart the process. If it won’t stay started after a few tries, it’ll stop and switch the process to maintenance mode, meaning you get to fix it.

The second is its ability to break out instances of an application by essentially subclassing the main “default” instance and redefining configuration variables, such as which config file to read, where to keep the database, etc. This means you can, with a few commands, bring up another instance of apache for testing, or maybe a number of mongrels serving different apps, from the generic service definition.

Sun has a pretty good how-to online dealing with postgresql, which is helpful, but leaves out a few chunks. SMF expects you to provide it with start and stop methods, which is helpful if you just want to move a legacy service over to SMF, but some applications are simpler than that and work fine by just running them and sending them a kill signal when they need to go away. In this case, you can just give the command to launch the daemon as the start method, and fill the stop method with :kill. This will instruct SMF to send a kill signal to the process and children executed by the start method. Incidentially, if the app reloads configuration when sent -HUP, you can fill in :kill -HUP as the refresh method. This isn’t explicitly spelled out in any documentation I’ve read, but it’s used in a few places in the manifests that ship with Solaris.

Below is a manifest I whipped up for mt-daapd, which scans and shares out all of my spiffy tunes so itunes can play ’em.

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="manifest" name="mt-daapd">
    <service name="network/mt-daapd" type="service" version="1">
        <dependency name="network" grouping="require_all" restart_on="none" type="service">
            <service_fmri value="svc:/milestone/network:default"/>
        <exec_method type="method" name="start" exec="/export/home/pjjw/opt/pkgs/mt-daapd/sbin/mt-daapd -y -c %{mt-daapd/conffile}" timeout_seconds="10" />
        <exec_method type="method" name="refresh" exec=":kill -HUP" timeout_seconds="10" />
        <exec_method type="method" name="stop" exec=":kill" timeout_seconds="10" />
        <instance name="default" enabled="false">
            <property_group name='config' type='application'> 
                <propval name='conffile' type='astring' value='/export/home/pjjw/opt/pkgs/mt-daapd/etc/mt-daapd.conf' /> 
        <stability value="Evolving"/>
                <loctext xml:lang="C">Firefly Media Server</loctext>
                <doc_link name="Firefly Media Server homepage" uri=""/>

I run two instances of this app- one which shares out the music that i’ve sorted and tagged properly, and then another one that shares out stuff that’s just arrived into torrent directories or the like. Ignore the ridiculous location I’ve installed this app to and note the property group and properties. I’ve got two config files, one describing one configuration, and another describing the other. I can make the second instance from the first with the following commands:

svccfg -s network/mt-daapd add incoming
svccfg -s network/mt-daapd:incoming setprop config/conffile = astring: /export/home/pjjw/opt/pkgs/mt-daapd/etc/incoming.conf 

..and there it is, a new instance of the server.

[00:28:05][pjjw@push:~]$ svcs mt-daapd
STATE          STIME    FMRI
online         Oct_17   svc:/network/mt-daapd:incoming
online         Oct_17   svc:/network/mt-daapd:default

I’d actually just been running this in screen for about 6 months and restarting it when it crashed. This is much nicer now.