Silos and projects
Silos and Projects let teams share infrastructure while keeping ownership and access separate. Fleet administrators control which infrastructure a Silo can use; Project membership controls work inside that Silo. Before creating a shared workspace, decide which Silo owns it, who needs access and which resources it may consume.
Create and select a project
Each Account receives a Personal project in its home Silo. Use a Shared project when several Accounts or Groups need the same VMs. A Personal project cannot be converted into a general shared workspace by adding members.
- Open Projects in the intended Silo and choose New project.
- Enter Name and Description, and review Default pool and any quota settings offered to your role.
- Select Create project.
- Open Project access and add the required Accounts or Groups with the appropriate role.
- Review Utilization before provisioning workloads.
Silo and Fleet administrators can create Shared projects. Other Silo members can do so only when the Silo allows member creation; that setting is off by default. Project collaborators can operate and create workloads, viewers can read them, and Project administrators also manage the Project itself.
Control visibility and quotas
A Fleet administrator manages Silos through System, Silos. Each Silo's resource visibility determines which Pools, SRs, external Networks and Catalog images are available to its Projects. Project creation permission alone does not make a hidden SR available.
Project quotas cover vCPUs, memory, storage and IP addresses. Silo quotas cap aggregate provisioning across Projects. A new allocation must fit both applicable limits. Utilization describes provisioning against quotas; it is not the same measurement as current CPU load or memory used inside a VM.
To work in another Silo, a Fleet role holder opens that Silo and selects Enter silo. Check the acting-Silo indication before creating anything. Return to the home Silo when finished. Fleet access in another Silo does not create a Personal project there; name the intended Project explicitly.
Verify ownership
After creating a Project, sign in with a representative member and confirm that its VMs, Images and VPCs are visible and its role allows only the intended operations. Confirm that an image shared at Silo level appears where expected. Catalog visibility and Project image ownership are separate mechanisms.
For existing workloads, System, Unassigned exposes resources without Project ownership. Adoption changes management ownership; it is not a live migration to another Host. Inspect the selected resource and destination before using that operation.
Common problems
An empty creation selector usually needs a visibility or ownership check. A quota error needs a review of both Project and Silo limits, not just free physical capacity. A missing create button may reflect the member-creation policy. Deletion can be refused while a Silo still owns Projects or Accounts; removing its last administrator is also protected unless a Fleet administrator acts. Keep an administrator path working while changing membership.