You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by an...@apache.org on 2023/11/28 19:58:48 UTC

(cloudstack-documentation) branch kvm_ingestion-andrija updated: Update importing_unmanaging_vms.rst

This is an automated email from the ASF dual-hosted git repository.

andrijapanic pushed a commit to branch kvm_ingestion-andrija
in repository https://gitbox.apache.org/repos/asf/cloudstack-documentation.git


The following commit(s) were added to refs/heads/kvm_ingestion-andrija by this push:
     new 70353f3  Update importing_unmanaging_vms.rst
70353f3 is described below

commit 70353f37fa62f0a7b3de024b3086d13a90ec4701
Author: Andrija Panic <45...@users.noreply.github.com>
AuthorDate: Tue Nov 28 20:58:44 2023 +0100

    Update importing_unmanaging_vms.rst
---
 .../virtual_machines/importing_unmanaging_vms.rst  | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/source/adminguide/virtual_machines/importing_unmanaging_vms.rst b/source/adminguide/virtual_machines/importing_unmanaging_vms.rst
index c6f48d8..224ba74 100644
--- a/source/adminguide/virtual_machines/importing_unmanaging_vms.rst
+++ b/source/adminguide/virtual_machines/importing_unmanaging_vms.rst
@@ -16,7 +16,7 @@
 About Import Export Instances
 -------------------------
 
-CloudStack supports Import of Instances from Managed Hosts, External Hosts, Local Storage and Shared Storage.
+For certain hypervisors, CloudStack supports importing of Instances from Managed Hosts, External Hosts, Local Storage and Shared Storage, into CloudStack.
 
 Manage or Unmanage Instances on Managed Hosts
 -------------------------
@@ -24,17 +24,17 @@ Manage or Unmanage Instances on Managed Hosts
 .. note:: This is currently only available for **vSphere** and **KVM** clusters.
 
 
-As of ACS 4.14, CloudStack has the concept of **unmanaged** Instances.  These are Instances that are on CloudStack
-managed hosts, but that are not in CloudStack's database and therefore CloudStack cannot control (manage) then in any way.  Previously,
+As of ACS 4.14, CloudStack has the concept of **unmanaged** Instances.  These are Instances that are on CloudStack-managed hosts, 
+but that are not in CloudStack's database and therefore CloudStack cannot control (manage) them in any way.  Previously,
 such Instances could exist, but CloudStack did not 'see' them (their existence *would* be reported in logs as unrecognised Instances).
 
-From ACS 4.14 onwards, CloudStack is able to list these Instances via the listUnmanagedInstances API command and then import (also known as ingest)
-those unmanaged Instances via the importUnmanagedInstance API so that they become CloudStack managed Guest Instances.
-From ACS 4.16 onwards, importing of the unmanaged Instances can also be carried out within the UI.
+From ACS 4.14 onwards, CloudStack is able to list VMware-based unmanaged instances via the listUnmanagedInstances API command and then import (also known as ingest)
+those unmanaged Instances via the importUnmanagedInstance API so that they become CloudStack-managed Guest Instances.
+From ACS 4.16 onwards, importing unmanaged Instances can also be carried out within the UI.
 
-From ACS 4.15 onwards, administrators are able to unmanage guest Instances.
+From ACS 4.15 onwards, administrators are able to unmanage VMware-based guest Instances.
 
-From ACS 4.19, this feature is available for KVM hosts also.
+From ACS 4.19, CloudStack also supports importing KVM-based guest instances.
 
 In the UI, both unmanaged and managed Instances are listed in *Tools > Import-Export Instances* section:
 
@@ -47,12 +47,12 @@ Importing Unmanaged Instances
 Use Cases and General Usage
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ability to import Instances allows Cloud operators (both public and private) to onboard new tenants simply and quickly,
-with the minimum amount disk IO. But also can be used in disaster recovery scenarios at remote sites (if storage is
+The ability to import Instances allows Cloud operators to onboard new tenants simply and quickly,
+with the minimum amount of disk IO. It can also be used in disaster recovery scenarios at remote sites (if storage is
 replicated) and in the recreation of Instances which have been backed up (part of the code is indeed used in
 CloudStack's Backup and Recovery feature).
 
-The most complex part of importing Instances is the mapping of an unmanaged Instance's Networks to CloudStack Networks.  As an operator
+The most complex part of importing Instances is the mapping of an unmanaged Instance's Networks to CloudStack Networks, as an operator
 could be importing tens or even hundreds of Instances.
 
 If the 'destination' Network VLAN(s) and the requested service offerings match the existing Instance, then the Instance can be