Adding a ZFS filesystem on loopback mount to a SmartMachine

  • Wed 19 March 2014
  • misc

It turns out that vmadm (the ultra-spiffy JSON-eating wrapper around zoneadm, zlogin, and friends) is not quite capable of doing everything you might want to do to a SmartMachine/zone, particularly when it comes to modification. This is not entirely surprising; the culture of administering SmartMachines centers around a death/rebirth archetype - after all, when your provisioning and post-provisioning tweaks are all automated (with a suitable assortment of one or more of vagrant, puppet, cfengine, chef, etc) logging in and manually changing stuff is actually a step away from goodness.

In some cases, maybe all but I haven't taken the time to verify this with a complete read of vmadm's source, it's possible to go behind vmadm's back and do things to an existing zone that vmadm does not support.

In the case at hand, we've recently had a laptop shuffle here at Chez RS. As previously written we point Time Machine at a server running SmartOS, with a separate ZFS partition for each Mac, the better to individually manage snapshots and backups.

We don't want to reuse the old TM partition for Kim's laptop; we want to create a new one and freeze the old one (already done with a ZFS snapshot). How to add this ZFS partition to an existing SmartMachine is enumerated below.

{% raw %} [root@a0-b3-cc-e8-95-9a ~]# zfs create zones/tm/kimby-new-mbp2009 [root@a0-b3-cc-e8-95-9a ~]# vmadm stop c45b96a0-75ff-4108-82e7-93be4ae881f6 [root@a0-b3-cc-e8-95-9a ~]# zonecfg -z c45b96a0-75ff-4108-82e7-93be4ae881f6 zonecfg:c45b96a0-75ff-4108-82e7-93be4ae881f6> add fs zonecfg:c45b96a0-75ff-4108-82e7-93be4ae881f6:fs> set dir=/tm/kimby-new-mbp2009 zonecfg:c45b96a0-75ff-4108-82e7-93be4ae881f6:fs> set special=/zones/tm/kimby-new-mbp2009 zonecfg:c45b96a0-75ff-4108-82e7-93be4ae881f6:fs> set type=lofs zonecfg:c45b96a0-75ff-4108-82e7-93be4ae881f6:fs> end zonecfg:c45b96a0-75ff-4108-82e7-93be4ae881f6> commit zonecfg:c45b96a0-75ff-4108-82e7-93be4ae881f6> exit [root@a0-b3-cc-e8-95-9a ~]#

At this point, if you type {% raw %} vmadm get c45b96a0-75ff-4108-82e7-93be4ae881f6 {% endraw %} you can see that vmadm knows about the new filesystem. It knows how to set up the loopback filesystem as part of vmadm create too; it just doesn't know how to handle it with vmadm update. Bummer. Anyway, now we can start the zone and add the new filesystem to netatalk's config.