anchor.diff:  [[brown-field]]
   ## Brown-field deployment
   
  - * Deploying this on an existing DC
  +Deployment to an existing DC will require at least one empty compute node.
  +The operator starts by installing kbmapi on the head node by running
  +`sdcadm post-setup kbmapi`.  This will install and start the KBMAPI service on
  +the head node.  Once complete, the operator proceeds to run the setup
  +process on the empty nodes.  The empty nodes must have a PIV token inserted
  +at the time of setup.  The setup program will provision the PIV token (using
  +piv-tool), create the encrypted zpool, and store the pin information in KBMAPI.
  +
  +Once setup, instances can be provisioned as well as migrated to the encrypted
  +CN.
  +
  +Conversion of the head node to an encrypted zpool will be covered by a
  +separate RFD (TBD).
   
   ## Implementation and intermediate states
   
  
positive.code: We will not have a hard dependency on these extensions in the implementation of
  this RFD, but we may implement optional support for using them.
  
  ### Operating system infrastructure
  
  Most other open-source operating systems (e.g. GNU/Linux distributions) use a
  
negative.code:    been chosen, assuming that AES-NI or SSE3 are available, it is desirable to
     not have to require these CPU features for the system to operate safely.
  
  ## Recovery Scenarios
  
  This is currently a placeholder, the intention is to add recovery scenarios
  and the example steps that would occur to recover. The design is such that
  as long as the `rfd77:config` property is intact, one should be able to either
  use the token 9a key or N of M recovery secrets (assigned to individuals) to
  recover the encryption key and mount the zpool.  We want to be able to validate
  the sequence of steps (including potential mis-steps) with the actions of
  KBMAPI and kbmd to minimize (or hopefully eliminate) any scenarios that lead to
  the loss of the zpool encryption key (and thus loss of data in the zpool).
  