-
Notifications
You must be signed in to change notification settings - Fork 121
Document KVM VM metadata handling in unmanage process #595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 4.22
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -360,6 +360,10 @@ The API has the following preconditions: | |||||
| - The Instance state must be 'Running’ or ‘Stopped’ | ||||||
| - The Instance must be a VMware Instance (as of CloudStack 4.19, it's also possible to unmanage a KVM-based Instances) | ||||||
|
|
||||||
| .. warning:: | ||||||
| Starting with the 4.22.0 release, when a KVM VM is unmanaged, its infrastructure metadata (zone, pod, cluster, and host) in the libvirt VM XML is preserved. | ||||||
|
||||||
| Starting with the 4.22.0 release, when a KVM VM is unmanaged, its infrastructure metadata (zone, pod, cluster, and host) in the libvirt VM XML is preserved. | |
| Starting with the 4.22.1 release, when a KVM instance is unmanaged, the infrastructure metadata (zone, pod, cluster, and host details) is preserved in the libvirt VM XML. |
Note: if any change in the retaining behavior, mainly clearing the metadata while unmanaging instance is handled before 4.22.1, this warning message is not needed and has to be reverted. cc @DaanHoogland
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sureshanaparti
Suresh, prior to 4.22.1, the preserved libvirt XML behavior was meant to support non-transient domains required for unmanaged VMs. During that process, no CloudStack metadata was stored — it only started being preserved after the libvirt metadata enhancement. I think this is worth mentioning in the release notes. Please correct me if I’m mistaken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sureshanaparti
Changes applied as suggested — ready for review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sureshanaparti Suresh, prior to 4.22.1, the preserved libvirt XML behavior was meant to support non-transient domains required for unmanaged VMs. During that process, no CloudStack metadata was stored — it only started being preserved after the libvirt metadata enhancement. I think this is worth mentioning in the release notes. Please correct me if I’m mistaken.
fine, we can mention that. I'm making a point that if any PR addresses the cleanup of the libvirt metadata in 4.22.1 itself, this note in the doc has to revisited.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This information is already document in this PR https://github.com/apache/cloudstack-documentation/pull/562/files
is this something else ?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@harikrishna-patnala
This is different from https://github.com/apache/cloudstack-documentation/pull/562/files.
It focuses on retaining CloudStack metadata on libvirt XML even after the VM resource is unmanaged from ACS.