Imported Resources¶
You don't have to rebuild what already runs in your cloud. You can import existing virtual machines, networks, firewalls, routers and SSH keys, and the platform lists and tracks them next to the resources you create. For each imported resource you decide whether the platform may change it in your cloud (Read-only or Managed), whether it may ever delete it (Take ownership), and how to remove it from the platform later (Detach or Delete).
This page is the reference for importing and for those choices. The pages for each resource type only add what is specific to that type.
Importing works on OpenStack infrastructures. Choosing Read-only or Managed and taking ownership are available if your platform operator has enabled them; see If you don't see these options.
The rule in one sentence¶
An imported resource is tracked by the platform, changed in your cloud only while it is Managed, and deleted from your cloud only after you take ownership of it; otherwise you remove it from the platform with Detach, which leaves it running in your cloud.
| Read-only | Managed | Owned (either mode) | |
|---|---|---|---|
| Listed and tracked, rename and edit description | Yes | Yes | Yes |
| Used by other resources (attach VMs to the network, apply the firewall, pick the SSH key) | Yes | Yes | Yes |
| Changes that reach your cloud (rules, DHCP, routes, VM power, and so on) | No | Yes | Depends on mode |
| Delete (destroys it in your cloud) | No | No | Yes |
| Detach (removes it from the platform only) | Yes | Yes | Yes |
A resource's Origin, in lists and on its page, shows whether it was created or imported, and in which mode.
Imported resources count toward your organization's quotas exactly like the ones you create.
What you can import¶
| Resource | What you pick in your cloud | Modes |
|---|---|---|
| Virtual machines | A server | Read-only or Managed |
| Networks | A network and one of its subnets | Read-only or Managed |
| Firewalls | A security group | Read-only or Managed |
| Routers | A router | Read-only or Managed |
| SSH keys | A keypair | Always read-only |
Flavors and images are not imported here. They go into the infrastructure's Catalog.
Import a resource¶
- Open the resource's list page (for example COMPUTE & NETWORK > Networks) and click its Import button, for example Import Network. For networks, firewalls and SSH keys, the button is on your own list, not on Shared with me.
- Choose the project that will hold the resource and the infrastructure it lives on.
- Pick the object in your cloud. The list is read live from your cloud, from the OpenStack project the infrastructure's credentials use (plus shared and external networks).
- Choose Read-only (the default) or Managed. See Read-only and Managed.
- Optionally give it a name and description in the platform, then confirm.
The pick list leaves out objects that can never be imported, such as the security group the platform adds to each VM and anything created for a Kubernetes cluster. It can still show objects the platform created for your own networks, routers, firewalls and VMs, and objects already imported into the project. Importing those is refused with an explanation. To use a platform-created network, firewall or SSH key in another project, share it instead. Each cloud object can be imported once per project.
Import what a resource depends on first¶
An imported resource can only reference things the platform already knows about, owned by the target project or shared with it:
- Virtual machine: its flavor must be in the infrastructure's catalog, and so must its image (unless your cloud no longer has that image). Every network it is attached to must be imported as a network, and every security group on its network interfaces as a firewall. Unknown security groups are not skipped: the import is refused. Its SSH key must be imported too, if the key belongs to the cloud user the infrastructure's credentials sign in as. Most hand-built servers carry the cloud project's
defaultsecurity group, so you usually need to import that as a firewall first. - Router: its external gateway network and every network attached to it.
If anything is missing, the import is refused with one message that lists everything still to import. A good order is: catalog entries, then networks, firewalls and SSH keys, then routers and virtual machines.
Read-only and Managed¶
An imported network, firewall, router or virtual machine is either Read-only or Managed.
- Read-only: you can rename the resource and edit its description, and other resources can use it. Changes that would reach your cloud are not available: VM power, resize, monitoring, network attachments, firewalls on its interfaces and backups; network DHCP; firewall rules; router networks and static routes; and Sync for all of them.
- Managed: those changes are applied to the object in your cloud, with the usual permissions for each operation.
Neither mode lets the platform delete the object. That needs ownership.
Good to know before you choose:
- A read-only record is a snapshot. The platform keeps what it recorded at import, such as a VM's network interfaces and security groups, or a firewall's rules. Later changes made directly in your cloud don't show up. To pick them up, detach the resource and import it again.
- A managed VM keeps its firewalls. If someone removes one of its security groups directly in your cloud, the platform puts it back on its next change. Groups added outside the platform are left alone. To stop the platform from touching a server, for example during an incident, return it to read-only or detach it.
- SSH keys are always read-only. A keypair can't be changed after it exists.
A managed firewall doesn't show the rules already in your cloud
When a firewall becomes managed, the snapshot of rules taken at import is dropped, and the firewall starts with an empty rule list in the platform. The rules that already exist in the security group are not deleted: they stay active in your cloud, but the platform doesn't show or manage them. Before you enable management, record the existing rules, and review or remove them directly in your cloud, so that traffic you don't see in the platform isn't left open.
Switch between Read-only and Managed¶
On the resource's page, open Actions, select Enable management or Return to read-only, and confirm. You can switch back and forth at any time. Returning to read-only stops changes to your cloud; it is not a detach.
Enabling management is refused when:
- Another project already manages or owns the object. Several projects can import the same object, but only one project at a time can manage or own it, and management and ownership must sit in the same project.
- The object doesn't belong to your cloud project. Only objects that belong to the OpenStack project the infrastructure's credentials use can be managed. Networks that are shared or external in your cloud, and objects that belong to someone else, stay read-only.
- A VM no longer matches what was recorded. If network interfaces or security groups were added or removed in your cloud since the import, the switch is refused and the message names each difference. Detach the VM and import it again.
- The VM isn't this project's oldest import. See Virtual machines imported by several projects.
Restricted firewalls¶
The cloud project's default security group protects every server in that OpenStack project that was booted without an explicit group, including servers the platform has never seen. It can be imported only as read-only, and it can't be managed, owned or deleted from the platform. You can keep it read-only, or detach it once nothing uses it.
Virtual machines imported by several projects¶
When several projects import the same server, only the project with the oldest import still on the platform can manage it, take ownership of it, and open its console and console logs. The other imports stay read-only views. If the oldest import is detached, the next-oldest one gains these rights. Importing a server directly as Managed is refused while another project already has it.
Take ownership¶
Importing a resource doesn't make the platform responsible for it, which is why an imported resource can be detached but not deleted. Take ownership records that the platform is now responsible for the object and makes Delete available.
On the resource's page, open Actions, select Take ownership, and confirm.
- Nothing changes in your cloud. Ownership only allows a later delete.
- The same limits as management apply: one project at a time, the same project that manages the object (if any), and only objects that belong to your cloud project. For an SSH key, the keypair must have been created by the cloud user the infrastructure's credentials sign in as. Objects that fail these checks can only be detached.
- Ownership is independent of the mode. A read-only resource can be owned, and a managed one doesn't have to be.
- The console doesn't offer a way to give ownership back.
Delete or detach¶
| Delete | Detach | |
|---|---|---|
| In the platform | Removed | Removed |
| In your cloud | Destroyed | Kept, no longer managed |
| Billing by your cloud provider | Stops | Continues |
| Platform quotas and usage | Released | Released |
| Getting it back | Not possible | Import the object again, as a new resource |
| Available for | Resources you created, and imported resources you own | Any resource, created or imported |
Detach keeps the object, and its costs, in your cloud
After a detach, the platform no longer counts the resource or reports its usage, but the object keeps running in your cloud account and keeps costing money. Make sure whoever runs it knows it is now unmanaged.
A resource's Actions menu always offers Detach, and offers Delete for resources you created and imported resources you own.
Both are refused while something still uses the resource, in any project: for example a network that a VM or router is attached to, or a firewall or SSH key that a VM uses. View dependencies lists each blocking resource and its project. You confirm by typing the resource's name.
When you detach, a VM keeps running with its data and volumes, a router keeps its network attachments and static routes, and networks, firewalls and SSH keys stay as they are. Deleting an owned router never deletes the networks it was connected to.
If you don't see these options¶
If your platform operator hasn't enabled them, the console doesn't show the Read-only or Managed choice, Enable management, Return to read-only or Take ownership. Every import is then read-only, and you can detach imported resources but not delete them. Delete appears only if your platform operator has taken ownership for you. Ask your platform operator if you need an imported resource managed or deleted.
If the options are shown but your role lacks the permission, the action is refused with a message that says so.
Permissions¶
Each action has its own permission. <family> is mvms for virtual machines, or network, firewall, router or sshkey.
| Task | Permission |
|---|---|
| Import | <family>_import |
| Import as Managed, Enable management, Return to read-only | <family>_control_update (not for SSH keys) |
| Take ownership | <family>_authority_update |
| Delete | <family>_delete |
| Detach | <family>_detach |
These permissions stand alone: <family>_update and <family>_delete don't include them, and enabling management doesn't replace the permission for each change, such as resizing a VM or editing firewall rules. See the Permissions reference.