[Free as in beer] SMF service for VirtualBox VM's
Posted: 28. Jul 2010, 10:00
Post updated by Jim Klimov, 2010-08-27:
---
Hello, all.
Like many others, I wanted to run some VMs all the time regardless of host reboots.
And on Solaris/OpenSolaris hosts this is facilitated by SMF services.
Almost a year ago Alexandre Dumont published his SMF method script and manifest, and they allowed to do just that: register each VM as an instance of the SMF service and enable or disable it. It also allowed management of VMs owned by a non-root user (via service credentials) and, of course, SMF allows to set up dependencies between VMs, resources and other services.
http://adumont.serveblog.net/2009/09/01 ... box-smf-2/
Over the past months I've used and extended this service:
* to enable management of paused VMs,
* savestate and restore the VMs (i.e. on service disable/enable),
* run certain VMs with a tweaked NICE priority,
* reboot VMs gracefully via acpibutton-poweroff-poweron or ingracefully reset actions,
* monitor the VM state according to VirtualBox (i.e. aborted, saved, etc.) and appropriately reflect this in SMF service state (cause maintenance or offline state), or start up the VM,
** can count how many aborted states there were over the past X seconds and cause maintenance for a frequently failing VM (i.e. when the NFS sever with its virtual disk is down, etc.),
* a number of command-line modes for the manifest script, including the ability to save VM state, restart it with a GUI mode for manual maintenance, and when you're done - save state again and the VM will be managed by its SMF service again,
* UNTESTED hooks to call external scripts which can poll the VM's services to see if it is alive inside.
Updates in release 0.11 as a difference from previously published 0.09:
* Add processing for VBox empty state as a temporary error (retry next cycle),
* Added a flag to cause all 'offline' attempts to actually cause 'maintenance',
* Use `id` invokations good for both OpenSolaris and Solaris 10,
* add more definite dependencies for SMF service startup (milestone multi-user, filesystems/local; nfs/client and autofs are optional = required if enabled) as a result of debugging our occasional failures with VMs running off NFS storage,
** for users implementing iSCSI this should probably provide a template to require iSCSI clients to start before VMs.
All thinkable variables have been parametrized with SMF service properties (group "vm/" or system props in groups "start/", "stop/", etc.), and properties not defined at the instance level (i.e. "svc:/site/xvm/vbox:VM_NAME") will be queried from the common service level (i.e. "svc:/site/xvm/vbox").
Feel free to test this in your environment, and please report back whether this worked well or not, or what can be fixed/improved. Patches are welcome
Hopefully this would not ruin your system, but beware that some PID- and LOCK-files are used: created and removed. Some of this activity can be enabled or disabled per-instance, any filenames used can be hardwired into SMF properties (must be unique!). See comments in XML manifest for more details.
Hope this helps,
//Jim Klimov
---
Hello, all.
Like many others, I wanted to run some VMs all the time regardless of host reboots.
And on Solaris/OpenSolaris hosts this is facilitated by SMF services.
Almost a year ago Alexandre Dumont published his SMF method script and manifest, and they allowed to do just that: register each VM as an instance of the SMF service and enable or disable it. It also allowed management of VMs owned by a non-root user (via service credentials) and, of course, SMF allows to set up dependencies between VMs, resources and other services.
http://adumont.serveblog.net/2009/09/01 ... box-smf-2/
Over the past months I've used and extended this service:
* to enable management of paused VMs,
* savestate and restore the VMs (i.e. on service disable/enable),
* run certain VMs with a tweaked NICE priority,
* reboot VMs gracefully via acpibutton-poweroff-poweron or ingracefully reset actions,
* monitor the VM state according to VirtualBox (i.e. aborted, saved, etc.) and appropriately reflect this in SMF service state (cause maintenance or offline state), or start up the VM,
** can count how many aborted states there were over the past X seconds and cause maintenance for a frequently failing VM (i.e. when the NFS sever with its virtual disk is down, etc.),
* a number of command-line modes for the manifest script, including the ability to save VM state, restart it with a GUI mode for manual maintenance, and when you're done - save state again and the VM will be managed by its SMF service again,
* UNTESTED hooks to call external scripts which can poll the VM's services to see if it is alive inside.
Updates in release 0.11 as a difference from previously published 0.09:
* Add processing for VBox empty state as a temporary error (retry next cycle),
* Added a flag to cause all 'offline' attempts to actually cause 'maintenance',
* Use `id` invokations good for both OpenSolaris and Solaris 10,
* add more definite dependencies for SMF service startup (milestone multi-user, filesystems/local; nfs/client and autofs are optional = required if enabled) as a result of debugging our occasional failures with VMs running off NFS storage,
** for users implementing iSCSI this should probably provide a template to require iSCSI clients to start before VMs.
All thinkable variables have been parametrized with SMF service properties (group "vm/" or system props in groups "start/", "stop/", etc.), and properties not defined at the instance level (i.e. "svc:/site/xvm/vbox:VM_NAME") will be queried from the common service level (i.e. "svc:/site/xvm/vbox").
Feel free to test this in your environment, and please report back whether this worked well or not, or what can be fixed/improved. Patches are welcome
Hopefully this would not ruin your system, but beware that some PID- and LOCK-files are used: created and removed. Some of this activity can be enabled or disabled per-instance, any filenames used can be hardwired into SMF properties (must be unique!). See comments in XML manifest for more details.
Hope this helps,
//Jim Klimov