F OpenNebula/one#6723: Remove 'onehost importvm'

source/installation_and_configuration/opennebula_services/oned.rst

@@ -363,45 +363,6 @@ The virtualization drivers are used to create, control and monitor VMs on the ho
 -  ``KEEP_SNAPSHOTS``: Do not remove snapshots on power on/off cycles and live migrations if the hypervisor supports that
 -  ``LIVE_RESIZE``: Hypervisor supports hotplug VCPU and memory. Values: ``YES`` or ``NO``
 -  ``SUPPORT_SHAREABLE``: Hypervisor supports shareable disks. Values: ``YES`` or ``NO``
--  ``IMPORTED_VMS_ACTIONS``: Comma-separated list of actions supported for imported VMs. The available actions are:
-
-   - ``migrate``
-   - ``live-migrate``
-   - ``terminate``
-   - ``terminate-hard``
-   - ``undeploy``
-   - ``undeploy-hard``
-   - ``hold``
-   - ``release``
-   - ``stop``
-   - ``suspend``
-   - ``resume``
-   - ``delete``
-   - ``delete-recreate``
-   - ``reboot``
-   - ``reboot-hard``
-   - ``resched``
-   - ``unresched``
-   - ``poweroff``
-   - ``poweroff-hard``
-   - ``disk-attach``
-   - ``disk-detach``
-   - ``nic-attach``
-   - ``nic-detach``
-   - ``disk-snapshot-create``
-   - ``disk-snapshot-delete``
-   - ``disk-snapshot-rename``
-   - ``disk-snapshot-revert``
-   - ``disk-resize``
-   - ``disk-saveas``
-   - ``resize``
-   - ``update``
-   - ``updateconf``
-   - ``snapshot-create``
-   - ``snapshot-delete``
-   - ``snapshot-revert``
-   - ``recover``
-   - ``retry``
 
 There are some non-mandatory attributes:
 
@@ -430,10 +391,7 @@ Sample configuration:
         TYPE           = "kvm",
         KEEP_SNAPSHOTS = "no",
         LIVE_RESIZE    = "yes",
-        SUPPORT_SHAREABLE    = "yes",
-        IMPORTED_VMS_ACTIONS = "terminate, terminate-hard, hold, release, suspend,
-            resume, delete, reboot, reboot-hard, resched, unresched, disk-attach,
-            disk-detach, nic-attach, nic-detach, snap-create, snap-delete"
+        SUPPORT_SHAREABLE    = "yes"
     ]
 
 .. _oned_conf_transfer_driver:

source/integration_and_development/infrastructure_drivers_development/devel-vmm.rst

@@ -63,7 +63,7 @@ These arguments are specified in the :ref:`oned.conf file <oned_conf>`, ``argume
         default    = "vmm_exec/vmm_exec_kvm.conf",
         ...
 
-Each driver can define a list of supported actions for :ref:`imported VMs <import_wild_vms>`. Please note that in order to import VMs, your monitoring drivers should report the :ref:`IMPORT_TEMPLATE variable <devel-im_vm_information>`. The complete list of actions is:
+Each driver can define a list of supported actions for :ref:`imported VMs <import_wild_vms>`. The complete list of actions is:
 
 .. _devel_actions:
 

source/intro_release_notes/release_notes/whats_new.rst

@@ -7,7 +7,7 @@ What’s New in |version|
 OpenNebula Core
 ================================================================================
 
-- Feature 1
+- Removed `onehost importvm` command for importing wild VMs.
 - Feature 2
 
 Storage & Backups

source/legacy_components/vcenter_driver/vcenter_datastores.rst

@@ -31,7 +31,7 @@ Disks attached to a VM will be backed by a non-persistent or persistent image, a
 Limitations
 --------------------------------------------------------------------------------
 
-* When a vCenter template or wild VM is imported into OpenNebula, the virtual disks are imported as OpenNebula images. If you get an error about not having enough datastore capacity to import VMs or images, please consider changing the "DATASTORE_CAPACITY_CHECK" in ``oned.conf`` to "no" and restarting OpenNebula.
+* When a vCenter template is imported into OpenNebula, the virtual disks are imported as OpenNebula images. If you get an error about not having enough datastore capacity to import VMs or images, please consider changing the "DATASTORE_CAPACITY_CHECK" in ``oned.conf`` to "no" and restarting OpenNebula.
 * No support for disk snapshots in the vCenter datastore.
 * Image names and paths cannot contain spaces or non ASCII characters.
 

source/legacy_components/vcenter_driver/vcenter_driver.rst

@@ -37,17 +37,11 @@ The following sections in the ``/etc/one/oned.conf`` file describe the informati
         KEEP_SNAPSHOTS    = "yes",
         DS_LIVE_MIGRATION = "yes",
         COLD_NIC_ATTACH   = "yes",
-        LIVE_RESIZE       = "yes",
-        IMPORTED_VMS_ACTIONS = "terminate, terminate-hard, hold, release, suspend,
-            resume, delete, reboot, reboot-hard, resched, unresched, poweroff,
-            poweroff-hard, disk-attach, disk-detach, nic-attach, nic-detach,
-            snapshot-create, snapshot-delete, migrate, live-migrate"
+        LIVE_RESIZE       = "yes"
     ]
     #-------------------------------------------------------------------------------
 
 
-IMPORTED_VMS_ACTIONS define which operations are allowed to be executed on imported VMs (Wild VMs).
-
 As a virtualization driver, the vCenter driver accepts a series of parameters that control its execution. The parameters allowed are:
 
 +----------------+-------------------------------------------------------------------+
@@ -126,7 +120,6 @@ Limitations
 -----------
 
 * only the disk-saveas operation is supported for VMs in the ``POWEROFF`` state.
-* imported Wild VMs cannot be stopped, undeployed nor ``recover --recreated``.
 
 
 vCenter Import Tool
@@ -151,7 +144,6 @@ The following vCenter resources can be easily imported into OpenNebula:
 * Datastores
 * Networks
 * VM Templates
-* Wild VMs (VMs launched outside of OpenNebula)
 * Images
 
 .. _vcenter_import_clusters:
@@ -460,106 +452,19 @@ If you modify a VM template and you edit a disk or NIC that was found by OpenNeb
 
 Before using your OpenNebula cloud, you may want to read about the :ref:`vCenter specifics <vcenter_specifics>`.
 
-.. _vcenter_import_wild_vms:
+.. _vcenter_wild_vms:
 
-Importing running Virtual Machines
+Wild Virtual Machines
 --------------------------------------------------------------------------------
 
-Once a vCenter cluster is monitored, OpenNebula will display any existing VM as Wild. These VMs can be imported and managed through OpenNebula once the Host has been successfully acquired.
-
-*Requirements*
-
-* **Before** you import a Wild VM you must have imported the datastores where the VM's hard disk files are located, as was explained before. OpenNebula requires the datastores to exist before the image that represents an existing virtual hard disk is created.
-* Running VM cannot have snapshots. Please remove them before importing.
-
-In the command line we can list wild VMs with the one Host show command:
-
-.. prompt:: text $ auto
-
-    $ onehost show 0
-      HOST 0 INFORMATION
-      ID                    : 0
-      NAME                  : MyvCenterHost
-      CLUSTER               : -
-      [....]
-
-      WILD VIRTUAL MACHINES
-
-                NAME                                                      IMPORT_ID  CPU     MEMORY
-                test-rp-removeme - Cluster                                  vm-2184    1        256
-
-      [....]
+Once a vCenter cluster is monitored, OpenNebula will display any existing VM as Wild.
 
 In Sunstone we have the Wild tab in the Host's information:
 
 .. image:: /images/vcenter_wild_vm_list.png
     :width: 70%
     :align: center
 
-VMs in running state can be imported as well as VMs defined in vCenter that are not in Power On state (this will import the VMs in OpenNebula in the poweroff state).
-
-.. _vcenter_wild_vm_nic_disc_import:
-
-A Wild VM import process creates images to represent the VM disks as well as new Virtual Networks if they are not already represented. If a Virtual Network exists already in OpenNebula, a network lease (IP/MAC) is requested for each IP reported for the VM by the VMware tools. If no AR contains the IP address space of the IP reported by the VM, a new AR is created and a lease requested. If the same NIC in the vCenter VM reports more than one IP, this is represented using NIC_ALIAS.
-
-It is important to clarify that in the event that a VM Template has multiple NICs and NIC ALIAS, they will be imported during this process.
-
-To import existing VMs you can use the 'onehost importvm' command.
-
-.. prompt:: text $ auto
-
-    $ onehost importvm 0 "test-rp-removeme - Cluster"
-    $ onevm list
-    ID USER     GROUP    NAME            STAT UCPU    UMEM HOST               TIME
-     3 oneadmin oneadmin test-rp-removem runn 0.00     20M [vcenter.v     0d 01h02
-
-Also, the Sunstone user interface can be used from the Host's Wilds tab. Select a VM from the list and click on the Import button.
-
-.. image:: /images/vcenter_wild_vm_list_import_sunstone.png
-    :width: 70%
-    :align: center
-
-Once a Wild VM is imported, OpenNebula will reconfigure the vCenter VM so VNC connections can be established once the VM is monitored.
-
-Also, network management operations are present, like the ability to attach/detach network interfaces, as well as capacity (CPU and MEMORY) resizing operations and VNC connections if the ports are opened beforehand.
-
-.. _vcenter_reimport_wild_vms:
-
-After a VM has been imported, it can be removed from OpenNebula and imported again. OpenNebula sets information in the vCenter VM metadata that needs to be removed, which can be done with the ``onevcenter cleartags`` command:
-
-- opennebula.vm.running
-- opennebula.vm.id
-- opennebula.disk.*
-- remotedisplay
-
-The following procedure is useful if the VM has been changed in vCenter and OpenNebula needs to "rescan" its disks and NICs:
-
-* Use onevcenter cleartags on the VM that will be removed:
-
-.. prompt:: bash $ auto
-
-    $ onevcenter cleartags <vmid>
-
-**vmid** is the id of the VM whose attributes will be cleared.
-
-* Un-register VM
-
-.. prompt:: bash $ auto
-
-    $ onevm recover --delete-db <vmid>
-
-* Re-import VM: on the Host's next monitoring cycle you will find this VM under **Wilds** tab and it can be safely imported.
-
-.. _vcenter_import_ip:
-
-If you want to set specific IPv4/6 when importing the VM, you can use the parameters ``--ipv4`` and ``--ipv6``, giving a list of IP addresses separated by commas.
-
-.. prompt:: bash $ auto
-
-    $ onehost importvm <host> <vm> --ipv4 ip1,ip2
-
-.. important:: You need to provide the IPs depending on your interfaces order, as they are going to be assigned in that order.
-
 .. _vcenter_import_networks:
 
 Importing vCenter Networks
@@ -792,10 +697,6 @@ Some aspects of the driver's behavior can be configured in */var/lib/one/remotes
 
 * **keep_non_persistent_disks**: Detach non-persistent disks from VMs on VM terminate but avoid deleting them afterwards. Default: **false**.
 
-* **keep_mac_on_imported**: Avoid change MAC from imported Wild. Default: **false**.
-
-* **wild_vm_persistent_images**: Wild VM disks imported as persistent (true) or non-persistent (false) images. Default: **true**.
-
 * **vm_template_persistent_images**: VM Template disks imported as persistent (true) or non-persistent (false) images. Default: **false**.
 
 * **sparse_images**: Sets the VMDK image subformat to sparse (true) or flat (false) for ESXi compatibility. Default: **false**.

source/legacy_components/vcenter_driver/vcenter_vms.rst

@@ -74,15 +74,14 @@ The monitoring attributes retrieved from a vCenter VM are:
 - VCENTER_VM_NAME: VM name on vCenter
 - DISK_x_ACTUAL_PATH: Physical path of the disk inside the vCenter datastore
 
-vCenter Template or Wild VM Importing Procedure
+vCenter Template Importing Procedure
 ================================================================================
 
-While a VM Template or Wild VM is being imported, OpenNebula will inspect the virtual disks and virtual nics and it will create images and virtual networks referencing the disks and port-groups used by the VM. This process may take some time, please be patient.
+While a VM Template is being imported, OpenNebula will inspect the virtual disks and virtual nics and it will create images and virtual networks referencing the disks and port-groups used by the VM. This process may take some time, please be patient.
 
 You have more information about these procedures:
 
 - :ref:`vCenter Template import <vcenter_template_import>`
-- :ref:`Wild VM import <vcenter_import_wild_vms>`
 
 .. _vcenter_cloning_procedure:
 
@@ -229,9 +228,9 @@ vCenter Images
 
 You can follow the common :ref:`Managing Images Section <images>`, considering that VMDK snapshots are not supported as well as the following considerations.
 
-OpenNebula scans VM Templates and Wild VMs for existing disks and it will create OpenNebula images that will represent those virtual disks. Thanks to this scanning process, existing disks will be visible for OpenNebula, and therefore can be detached from the deployed VMs. The following information is important about images created when a vCenter template or Wild VM is imported:
+OpenNebula scans VM Templates and Wild VMs for existing disks and it will create OpenNebula images that will represent those virtual disks. Thanks to this scanning process, existing disks will be visible for OpenNebula, and therefore can be detached from the deployed VMs. The following information is important about images created when a vCenter template is imported:
 
-- VM disks in imported as part of a VM Template or Wild VM are considered unmanaged images.
+- VM disks in imported as part of a VM Template are considered unmanaged images.
 - An unmanaged image won't be cloned by OpenNebula when a VM is instantiated. When OpenNebula deploys a VM, vCenter will clone the vCenter template and it will be  responsible of creating the copies of the template disks and attach them to the new Virtual Machine.
 - Although the images are considered unmanaged, you can perform operations like detaching the disks.
 - Virtual Machines in vCenter will have some variables created by OpenNebula that allows an OpenNebula disk element to be related with a vCenter Virtual Hard Disk. For example the unmanaged DISK with ID=0 has a variable called opennebula.disk.0 in vCenter's VM that stores a reference to the disk created by vCenter that will help OpenNebula identify what disk has to be detached.
@@ -262,7 +261,7 @@ The following image template attributes need to be considered for vCenter VMDK i
 | ``VCENTER_DISK_TYPE``       | The type of disk has implications on performance and occupied space. Values (careful with the case):  delta,eagerZeroedThick,flatMonolithic,preallocated,raw,rdm,rdmp,seSparse,sparse2Gb,sparseMonolithic,thick,thick2Gb,thin. More information `in the VMware documentation <http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.wssdk.apiref.doc%2Fvim.VirtualDiskManager.VirtualDiskType.html>`__.  |
 |                             | Known as "Disk Provisioning Type" in Sunstone.                                                                                                                                                                                                                                                                                                                                                                     |
 +-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``VCENTER_IMPORTED``        | It will be set to YES for images that have been imported when a vCenter template or Wild VM is imported. If this attribute is set to YES, OpenNebula **will not delete** the VMDK file in vCenter so you don't actually delete the hard disk attached to a template. If you remove this attribute the VMDK file will be deleted when the Image is deleted in OpenNebula.                                           |
+| ``VCENTER_IMPORTED``        | It will be set to YES for images that have been imported when a vCenter template is imported. If this attribute is set to YES, OpenNebula **will not delete** the VMDK file in vCenter so you don't actually delete the hard disk attached to a template. If you remove this attribute the VMDK file will be deleted when the Image is deleted in OpenNebula.                                                      |
 +-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 
 VMDK images in vCenter datastores can be:

source/management_and_operations/host_cluster_management/hosts.rst

@@ -107,7 +107,7 @@ To display information about a single Host, use the ``show`` command:
 
     WILD VIRTUAL MACHINES
 
-    NAME                                                      IMPORT_ID  CPU     MEMORY
+    NAME                                                      DEPLOY_ID  CPU     MEMORY
 
     VIRTUAL MACHINES
 
@@ -120,7 +120,7 @@ The information of a Host contains:
 * **Capacity** (*Host Shares*) for CPU and memory.
 * **Local datastore information** (*Local System Datastore*) if the Host is configured to use a local datastore (e.g. in SSH transfer mode).
 * **Monitoring Information**, including PCI devices and NUMA information of the node. You can also find hypervisor specific information here.
-* **Virtual Machines** allocated to the Host. *Wild* are virtual machines running on the Host but not started by OpenNebula, and can be imported.
+* **Virtual Machines** allocated to the Host. *Wild* are virtual machines running on the Host but not started by OpenNebula.
 
 To see a list of all the Hosts:
 
@@ -324,10 +324,10 @@ You can also select which Hosts you want to upgrade by naming them or selecting
 
 .. _import_wild_vms:
 
-Importing Wild VMs
+Wild VMs
 ================================================================================
 
-The monitoring mechanism in OpenNebula reports all VMs found in a hypervisor, even those not launched through OpenNebula. These VMs are referred to as Wild VMs and can be imported to be managed through OpenNebula. The Wild VMs can be spotted through the ``onehost show`` command:
+The monitoring mechanism in OpenNebula reports all VMs found in a hypervisor, even those not launched through OpenNebula. These VMs are referred to as Wild VMs. The Wild VMs can be spotted through the ``onehost show`` command:
 
 .. prompt:: bash $ auto
 
@@ -339,21 +339,10 @@ The monitoring mechanism in OpenNebula reports all VMs found in a hypervisor, ev
       STATE                 : MONITORED
       [...]
       WILD VIRTUAL MACHINES
-                          NAME                            IMPORT_ID  CPU     MEMORY
+                          NAME                            DEPLOY_ID  CPU     MEMORY
                  Ubuntu14.04VM 4223f951-243a-b31a-018f-390a02ff5c96    1       2048
                        CentOS7 422375e7-7fc7-4ed1-e0f0-fb778fe6e6e0    1       2048
 
-And imported using the ``onehost importvm`` command:
-
-.. prompt:: bash $ auto
-
-      $ onehost importvm 0 CentOS7
-      $ onevm list
-      ID USER     GROUP    NAME            STAT UCPU    UMEM HOST               TIME
-       3 oneadmin oneadmin CentOS7         runn    0    590M MyAWSHost  0d 01h02
-
-After a Virtual Machine is imported, its life-cycle (including creation of snapshots) can be controlled through OpenNebula. However, some  operations *cannot* be performed on an imported VM, including: poweroff, undeploy, migrate or delete-recreate.
-
 .. warning:: Wild VMs’ support and limitations may differ depending on the virtualization driver used (e.g KVM or LXC). In order to find more specific information for the virtualization driver you’re using, please check the corresponding driver guide.
 
 Using Sunstone to Manage Hosts