Repository navigation
KVM: assign device ID 0 to root volumes imported from shared/local storage - #14496
andrijapanicsb wants to merge 1 commit into
Conversation
…orage importVm with importsource=shared or importsource=local allocated the root volume with device ID 0, then overwrote it with an explicit ID 1 when finalizing the imported volume. Pass no device ID so the volume manager keeps the root default (0), as the other import paths do. Fixes apache#13771
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.22 #14496 +/- ##
============================================
- Coverage 18.26% 18.26% -0.01%
Complexity 16608 16608
============================================
Files 5939 5939
Lines 537697 537694 -3
Branches 65922 65922
============================================
- Hits 98210 98205 -5
+ Misses 428299 428297 -2
- Partials 11188 11192 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@blueorangutan package |
|
@andrijapanicsb a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
@ACSHomeBot package G |
|
Accepted: Planned: RPM + DEB, KVM SystemVM. Status: Queued for worker G. Jobs ahead: 0. |
|
Package building started on worker G. |
Packaging results:
Test packages are available at: |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19728 |
Description
This PR fixes the device ID of the ROOT volume when an existing KVM disk is adopted with
importVmandimportsource=sharedorimportsource=local.The shared/local KVM import allocates the root volume at device ID 0, then overwrites it with an explicit ID 1 during import finalization (
long deviceId = 1Lpassed toupdateImportedVolume()). Pass no explicit device ID so the existing root default remains 0, matching the other import paths (unmanaged/VMware-to-KVM viaimportDisk(), external KVM viaimportExternalDisk()).importKvmVirtualMachineFromDisk(): the explicit1Lis removed andnullis passed in both the shared and the local root-import calls.updateImportedVolume()already maps ROOT +nullto device ID 0; no null device ID is stored.Tests:
UnmanagedVMsManagerImplTest.importFromDisk(...), which is used by the four shared/local import tests, now verifies thatupdateImportedVolume()receivesVolume.Type.ROOTand anulldevice ID.updateImportedVolume()stub added by StorPool support importing standalone disk volumes and importVm from SHARED #14389 now accepts anulldevice ID (nullable(Long.class)).profile.getVolumeId()), so a stub limited toanyLong()would make the tests fail with a NullPointerException instead of on the verification.VolumeOrchestratorTestgets two focused tests forupdateImportedVolume(). They check the volume handed toVolumeDao.update():Related: #14407 (device ID conflicts between data volumes, CD-ROMs and the config drive ISO) changes data-disk allocation in the other import paths. It is independent of this fix, and neither needs the other to be merged first.
Fixes: #13771
Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
How Has This Been Tested?
Unit tests:
4.22atc4748669bf:UnmanagedVMsManagerImplTestran 93 tests with 4 failures and 0 errors.importFromLocalDisk,importFromsharedStorage,importFromsharedStorageOnRbdPoolandimportFromsharedStorageOnZoneWidePool.updateImportedVolume(ROOT, ..., 1L, ...)was called whereisNull()was expected.4.22atc4748669bf, and again after rebasing onto4.22at30ed411cff:UnmanagedVMsManagerImplTest: 93 tests, 0 failures.VolumeOrchestratorTest: 38 tests, 0 failures, including the two new tests.Combination with
mainand #14407:main(1abb539242) together with the server,kvm: Avoid device id conflicts between data volumes, CD-ROMs and the config drive ISO #14407 head (de91dd4417), using the main-branch variant of the test change (main has no StorPool support importing standalone disk volumes and importVm from SHARED #14389 stub yet).UnmanagedVMsManagerImplTest,VolumeOrchestratorTest,VolumeApiServiceImplTest,TemplateManagerImplTest,KVMGuruTestandLibvirtVMDefTest.UnmanagedVMsManagerImplTest: 128VolumeOrchestratorTest: 49VolumeApiServiceImplTest: 165TemplateManagerImplTest: 74KVMGuruTest: 33LibvirtVMDefTest: 29getReservedDeviceIdsAlwaysReservesTheCdromOfConfigDriveandgetNextDeviceIdSkipsReservedDeviceIds, the four shared/local import tests with the stricter verification, and the two newVolumeOrchestratorTesttests.Forward merge to
main:UnmanagedVMsManagerImplTestmerges without conflicts and brings thenullable(Long.class)stub along with the stricter verification.UnmanagedVMsManagerImplhas one conflict inimportKvmVirtualMachineFromDisk(). It already exists between4.22andmainwithout this change (StorPool support importing standalone disk volumes and importVm from SHARED #14389's refactor) and is not at the changed lines.VolumeOrchestratorTestmay conflict in the import list only (main has extra imports); keep both sides.Not tested: live imports. No guest boot or libvirt XML checks have been run yet.
How did you try to break this feature and the system with this change?