2014-02-09
Why I'm not looking at installing OmniOS via Kayak
As far as I can see, OmniOS's Kayak network install system is the recommended way to both install a bunch of OmniOS machines and to customize the resulting installs (for example to change the default sizes of various things). However, even setting aside my usual issues with automatic installers (which can probably be worked around) I've found myself uninterested in trying to use Kayak. The core problem for me is that Kayak only seems to really be supported on an OmniOS host.
The blunt truth is that we're not going to use OmniOS for very much here. It's going to run our fileservers, but while those are very important machines there are only a handful of them. I don't want to have to set up and manage an additional OmniOS machine (and a bunch of one-off infrastructure on that machine) simply to install a handful of fileservers with custom parameters and some additional conveniences. The cognitive overhead is simply not worth it. Things would be different if I could confidently host a Kayak system on an Ubuntu machine, as we have plenty of Ubuntu machines and lots of systems in place for running them.
I'm aware that there's some documentation for hosting Kayak on a Linux system. Unfortunately 'here's what someone tried once and got working' is not anywhere near as strong as 'we officially try to make this work and here is information on the general things Kayak needs and how it all works'. One of them means that people will take bug reports and the other one implies that if things break I'm basically on my own. I'm not putting crucial fileserver infrastructure into a 'you're on your own' setup; it would be irresponsible.
(Well, it would be irresponsible to do it when we don't have a relatively strong need to do so. We don't here, as manual OmniOS installs are basically as good as a Kayak install and are considerably less complex overall.)
2014-02-07
A surprise with OmniOS disk sizing: the rpool/dump ZVOL
Until recently, all of my work installing and reinstalling OmniOS has been in a virtual machine, which had a modest configuration. Recently I started doing test installs on our real fileserver hardware, which resulted in a disk sizing surprise in the default OmniOS install.
Our fileserver hardware has 64 GB of RAM and an 80 GB SSD system
disk (well, two of them but they're mirrored). On this hardware the
OmniOS installer set up a dedicated 32 GB chunk of space for kernel
dumps (the rpool/dump ZFS volume). On the one hand, this is very
much not what I wanted; I definitely don't want half of a quite
limited amount of disk space to disappear to something which I
expect to never use. On the other hand you can argue that this is
at least half rational as an OmniOS default, since OmniOS itself
needs almost no disk space. If you probably need 32 GB of kernel
dump space for safety and the disk space is there, you might as
well use it for something.
(I call this only half rational because I'm not sure there's enough
space left in /var to write out a kernel dump that actually needs
all of that 32 GB of dump ZVOL, since both OmniOS itself and the
swap ZVOL use of some of the remaining space.)
The normal installer image doesn't give you a convenient way to customize this, so my workaround is to simply delete the dump ZVOL after installation:
dumpadm -d none zfs destroy rpool/dump
If our OmniOS systems ever start crashing in a situation where a
crash dump might be useful, we can revisit this and perhaps recreate
a rpool/dump ZVOL of some suitable size.
(The OmniOS installer also defaulted to a 4 GB swap ZVOL. On the one hand this strikes me as excessive; on the other hand it's only 4 GB and swapping to and from a SSD is going to be a bunch faster than a traditional hard disk swap so having to go to swap might be quite as terrible as it used to be. We're leaving the swap ZVOL alone for now.)