Additional ICM Considerations

Single project namespace. ICM manages a single Lightbits project for volume, snapshot, and cluster operations. The project name is fixed at install time (ICM_PROJECT_NAME, default default) - and must already exist on every attached cluster. Requests that name a different project are rejected, and resources that live in another project are not visible to ICM's volume/snapshot APIs.

Thick-clone is the single-project exception. Thick-clone operations are deliberately project-agnostic; you can clone into any project on any attached cluster. As a consequence, a volume or snapshot cloned into a project other than ICM's configured project will not appear in icmcli list volumes / list snapshots and cannot be fetched or deleted through ICM. Manage it directly on the cluster with lbcli.

Up to 64 attached clusters. A single ICM instance manages at most 64 Lightbits clusters.

Linux only. ICM and its deployment tooling run on Linux hosts. See the Installing ICM article for the supported OS matrix.

Legacy DMS-compatible API is feature-frozen. For customers migrating from the Data Mobility Service, ICM serves a backward-compatible legacy API (/login and /api/v1/…) - so existing DMS clients keep working with no code change. This surface is maintained for compatibility only; it receives no new features and is slated for eventual retirement. New integrations should use the ICM API (/api/v2/…) and icmcli. dmscli is not supported against ICM.

Legacy workflow response fields. For legacy (/api/v1/) consumers only, the Workflow.input field is populated for attach-cluster workflows and the Workflow.details field is not populated. The ICM API and icmcli are unaffected.