Repository navigation
kvm: resolve RBD disks of unmanaged instances without a mount lookup - #14693
Open
weizhouapache wants to merge 1 commit into
Open
weizhouapache wants to merge 1 commit into
weizhouapache wants to merge 1 commit into
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
listUnmanagedInstances ran a substring mount lookup for every disk. For an RBD disk the pool name 'cloudstack' matched an unrelated NFS mount line, so the disk was reported on that NFS datastore and the import failed with 'Storage pool ... not found'. RBD disks now take the monitor host and the pool name from the libvirt source. Other disks, including Gluster network disks, keep the mount-based lookup. Add unit tests for the RBD and Gluster cases.
Copy link
Copy Markdown
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files @@ Coverage Diff @@
## 4.22 #14693 +/- ##
=============================================
- Coverage 18.32% 4.08% -14.24%
=============================================
Files 5939 449 -5490
Lines 537787 38282 -499505
Branches 65932 7083 -58849
=============================================
- Hits 98544 1564 -96980
+ Misses 428033 36503 -391530
+ Partials 11210 215 -10995
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness.
|
Sorry, something went wrong.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
listUnmanagedInstances ran a substring mount lookup for every disk. For an RBD disk the pool name 'cloudstack' matched an unrelated NFS mount line, so the disk was reported on that NFS datastore and the import failed with 'Storage pool ... not found'.
RBD disks now take the monitor host and the pool name from the libvirt source. Other disks, including Gluster network disks, keep the mount-based lookup.
Add unit tests for the RBD and Gluster cases.
Description
This PR...
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Unit tests (plugins/hypervisors/kvm): LibvirtGetUnmanagedInstancesCommandWrapperTest, 7 tests, all pass. The new cases check that an RBD disk takes the monitor host and pool name from the libvirt source without calling the mount lookup, and that a Gluster disk still uses the mount lookup.
Live test on a Trillian test environment (Ubuntu 26.04, two KVM hosts, Ceph RBD pools, management server and KVM agents built from this change):
Before this change the same disk was reported on the NFS mount that matched the pool name, and the import failed. The live run used an earlier build of the agent in which Gluster disks also took the RBD path. The RBD path is the same in both builds.
How did you try to break this feature and the system with this change?