Thursday Sep 10, 2009

Fastreboot and VirtualBox

I was getting some work done with virtualbox, vnics and
AI.

While VirtualBox does reboot rather fast since it virtualised, but why not faster ? Since the bug with VirtualBox and
OpenSolaris was fixed we should be able. And indeed we are.


By taking out VirtualBox from the blacklist of the boot-config SMF service we can then do Fastreboot within a VirtualBox guest with no issues :)


Let see what platforms are blacklisted.

$ svcprop -p fastreboot_blacklist/platforms boot-config
VirtualBox VMware\\ Virtual\\ Platform MCP55
$

Ok, lets take out VirtualBox.

$ svccfg -s boot-config:default setprop blacklist/platforms = astring: '("VMware Virtual Platform" "MCP55")'
$ svccfg -s boot-config:default refresh

Now VirtualBox can do fast reboot.


Thanks Darren for the trick with '(..)' for handling multiple strings in the property.

Thursday Jun 01, 2006

Jumpstart, patches and the world keeps turning.

Development within Sun is a fast paced F1 race track at times. While not as sunny and luxurious a location as Monte Carlo, Sun still has the racing speed. With new builds of Solaris (be it nevada or updates) every other week and patches incoming all the time for performance runs we can't afford to be the slowest pit crew on the track.

Automation is the name of the game here.

With patches there are a few ways of building a machine with a given release of Solaris and having it patches up, ready to roll all magik and nice. Jumpstart gives us a hook into the install process for us to drop in just about any scripts to do what we want.

You got a machine to reinstall, patch and get running ? Heres one way.

Say you've a machine or machines to install every now and again. So you've got a jumpstart server all ready to go. You're used to installing the machine and then logging on to add all those patches. Takes a while, you go for coffe while the patchadd goes on and on and on..

Jumpstart has a feature where you can add in your own scripts once the machine has been installed and before its been rebooted. Theres a rules file where you can name a script to be run after install. More details on this are at Custom JumpStart. This script along with knowing all your patches are in a nfs-shared path somewhere can let you automate all those patchadds. Leaving you to go more interesting things (thats your imagination, not mine :).

Anyhows heres the script

# Given a directory which contains all desired patches (unpacked),
# this script installs those patches.  The script is designed to be a post
# install script added in the rules file.

# $PATCH_URL can be a fullpath or a url to a location containing the patches
# to be installed
PATCH_URL=/net/machine/with/the/patches/unpacked

PATCH_LOG=/a/var/sadm/install/patch_install.log
PATCH_ERR=/a/var/sadm/install/patch_install.log

FatalErr () {
        echo "$0: $1"
        echo "$0: $1" >> $PATCH_ERR
        echo "Errors have been logged in $PATCH_ERR" | tee -a $PATCH_LOG
        exit 1
}
        
if [ ! -d $PATCH_URL ]; then
        FatalErr " Error: patch directory $PATCH_URL does not exist"
fi

echo "Adding patches contained at $PATCH_URL" | tee -a $PATCH_LOG

patchadd -M $PATCH_URL -R /a | tee -a $PATCH_LOG

exit 0

That script assumes you've a bunch of patches locally. What if you need to pick them up directly from Sun ? Patchadd can handle that like:

patchadd -k /etc/mycerts -P pass:abcd -x webcache.eng:8080 \\
     -M http://www.sun.com/solaris/patches/latest 101223-02 102323-02

as an example (straight from the manpage).

About

smg

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today