You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/adminguide/virtual_machines/importing_unmanaging_vms.rst
+37-1Lines changed: 37 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -339,7 +339,22 @@ Unmanaging Instances
339
339
340
340
Administrators can unmanage guest Instances from CloudStack. Once unmanaged, CloudStack can no longer monitor, control or administer the provisioning and orchestration-related operations on an Instance.
341
341
342
-
To unmanage a guest Instance, an administrator must either use the UI or invoke the unmanageVirtualMachine API passing the ID of the Instance to unmanage. The API has the following preconditions:
342
+
To unmanage a guest Instance, an administrator must either use the UI or invoke the unmanageVirtualMachine API passing the ID of the Instance to unmanage.
343
+
344
+
.. code:: bash
345
+
346
+
cmk unmanage virtualmachine id=<instance-id>
347
+
348
+
The API supports the `hostid` parameter for stopped instances on the KVM hypervisor, allowing the domain XML to be persisted on the specified host.
Instances with Config Drive cannot be unmanaged by default, as the Config Drive ISO will be removed during the unmanage operation. To unmanage such instances via the API, use the forced=true parameter.
356
+
357
+
The API has the following preconditions:
343
358
344
359
- The Instance must not be destroyed
345
360
- The Instance state must be 'Running’ or ‘Stopped’
The zone setting: unmanage.vm.preserve.nics can be used to preserve Instance NICs and its MAC addresses after unmanaging them. If set to true, the Instance NICs (and their MAC addresses) are preserved when unmanaging it. Otherwise, NICs are removed and MAC addresses can be reassigned.
363
378
364
379
380
+
Persistent KVM Domain XML for Unmanaged Instances
381
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
382
+
383
+
Since 4.22, the domain XML of an Instance is made persistent when it is unmanaged from CloudStack. This allows the Instance to be managed directly outside of CloudStack using `virsh` or other libvirt tools. The domain XML will be stored in the directory `/etc/libvirt/qemu` on the relevant KVM host.
384
+
385
+
Domain XML is taken from Instance but varies based on their state:
386
+
387
+
- Running Instance
388
+
- The existing domain XML is retrieved from the Instance and persisted on the host where the Instance is running.
389
+
- Stopped Instance
390
+
- The domain XML is reconstructed from the Instance details available in the CloudStack database.
391
+
- The reconstructed domain XML is persisted on the last host where the Instance was running before it was stopped. If that host is no longer available, the domain XML is saved on any other available host within the cluster.
392
+
393
+
.. note::
394
+
It is recommended to unmanage Instances while they are in the **Running** state to ensure that the exact domain XML is preserved. When unmanaged in the **Stopped** state, some information may be lost due to reconstruction.
395
+
396
+
365
397
Unmanaging Instance actions
366
398
~~~~~~~~~~~~~~~~~~~~~~~~~~~
367
399
@@ -426,6 +458,10 @@ Prerequisites
426
458
- Currently, it's supported to only use NFS and Local storage as the destination Primary Storage pools in CloudStack
427
459
- Currently, only libvirt-based instances can be migrated
428
460
461
+
.. note::
462
+
- Allocate a NIC to any instance without one immediately after importing it into CloudStack.
463
+
- Instances imported on a Config Drive network must be stopped and started after import to properly attach the Config Drive ISO.
0 commit comments