[VMware] Disk controller mappings #10454
Conversation
|
@blueorangutan package |
|
@winterhazel 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. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #10454 +/- ##
============================================
+ Coverage 16.58% 16.65% +0.07%
- Complexity 13870 13963 +93
============================================
Files 5719 5721 +2
Lines 507194 507098 -96
Branches 61573 61482 -91
============================================
+ Hits 84093 84446 +353
+ Misses 413681 413222 -459
- Partials 9420 9430 +10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 12549 |
|
@DaanHoogland it seems there were some merge issues in main. |
I'll check and update |
|
@winterhazel , please see #10457 . I have had no time (or infra) to test yet. |
|
@blueorangutan package |
|
@winterhazel 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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 12586 |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@winterhazel could you fix the conflicts? |
|
@blueorangutan package |
|
@winterhazel 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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13603 |
There was a problem hiding this comment.
Pull Request Overview
This PR refactors VMware disk controller handling by introducing a dynamic disk controller mapping backed by a new database table, adds support for SATA and NVMe controllers, and updates all callers to use the new DiskControllerMappingVO model.
- Centralize disk controller metadata in a new
disk_controller_mappingtable, DAO, VO, and loader logic. - Refactor
VmwareResourceand related classes to useDiskControllerMappingVOinstead of static enums, with full end-to-end support in start/attach flows. - Update API, schema, manager, and tests to load and propagate supported disk controllers at runtime.
Reviewed Changes
Copilot reviewed 29 out of 29 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| vmware-base/src/main/java/com/cloud/hypervisor/vmware/mo/ClusterMO.java | Change createBlankVm signature to use DiskControllerMappingVO. |
| vmware-base/src/main/java/com/cloud/hypervisor/vmware/mo/BaseMO.java | Add protected no-arg constructor |
| vmware-base/pom.xml | Add dependency on cloud-engine-schema |
| services/secondary-storage/controller/.../SecondaryStorageManagerImpl.java | Inject DiskControllerMappingDao and set supported controllers on setup |
| server/src/main/java/com/cloud/api/query/QueryManagerImpl.java | Replace hard-coded controller lists with dynamic DAO lookup |
| plugins/hypervisors/vmware/.../VmwareStorageProcessor.java | Simplify attachVolume to use DiskControllerMappingVO |
| plugins/hypervisors/vmware/.../VmwareSecondaryStorageResourceHandler.java | Handle new SecStorageVMSetupCommand |
| plugins/hypervisors/vmware/.../VmwareResource.java | Major refactor to use DiskControllerMappingVO for disk controller ops |
| plugins/hypervisors/vmware/.../VmwareManagerImpl.java | Load mappings at configuration time |
| plugins/hypervisors/vmware/.../VmwareVmImplementer.java | Update default root-controller detail to use enum |
| engine/schema/.../schema-42010to42100.sql | Create disk_controller_mapping table and seed default mappings |
| engine/schema/src/.../DiskControllerMappingDaoImpl.java & DiskControllerMappingDao.java | New DAO for disk controller mapping |
| engine/schema/src/.../DiskControllerMappingVO.java | New JPA entity for disk controller mapping |
| core/src/main/java/com/cloud/agent/api/SecStorageVMSetupCommand.java | Add field to carry supported disk controllers |
| String rootDiskControllerDetail = controllerInfo.get(VmDetailConstants.ROOT_DISK_CONTROLLER); | ||
| String dataDiskControllerDetail = controllerInfo.get(VmDetailConstants.DATA_DISK_CONTROLLER); |
There was a problem hiding this comment.
There’s no null-check for controllerInfo or its keys before calling get(...). Add a guard to avoid NPEs or provide a sensible default when controllerInfo is missing or incomplete.
| String rootDiskControllerDetail = controllerInfo.get(VmDetailConstants.ROOT_DISK_CONTROLLER); | |
| String dataDiskControllerDetail = controllerInfo.get(VmDetailConstants.DATA_DISK_CONTROLLER); | |
| String rootDiskControllerDetail = null; | |
| String dataDiskControllerDetail = null; | |
| if (controllerInfo != null) { | |
| rootDiskControllerDetail = controllerInfo.getOrDefault(VmDetailConstants.ROOT_DISK_CONTROLLER, null); | |
| dataDiskControllerDetail = controllerInfo.getOrDefault(VmDetailConstants.DATA_DISK_CONTROLLER, null); | |
| } |
Copilot uses AI. Check for mistakes.
| @@ -5320,8 +5325,9 @@ private void fillVMOrTemplateDetailOptions(final Map<String, List<String>> optio | ||
|
|
||
| if (HypervisorType.VMware.equals(hypervisorType)) { | ||
| options.put(VmDetailConstants.NIC_ADAPTER, Arrays.asList("E1000", "PCNet32", "Vmxnet2", "Vmxnet3")); | ||
| options.put(VmDetailConstants.ROOT_DISK_CONTROLLER, Arrays.asList("osdefault", "ide", "scsi", "lsilogic", "lsisas1068", "buslogic", "pvscsi")); | ||
| options.put(VmDetailConstants.DATA_DISK_CONTROLLER, Arrays.asList("osdefault", "ide", "scsi", "lsilogic", "lsisas1068", "buslogic", "pvscsi")); | ||
| List<String> availableDiskControllers = diskControllerMappingDao.listForHypervisor(HypervisorType.VMware).stream().map(DiskControllerMappingVO::getName).collect(Collectors.toList()); |
There was a problem hiding this comment.
[nitpick] The list of controller names is not sorted, which can lead to inconsistent option ordering in the UI. Consider sorting alphabetically to ensure a predictable user experience.
| List<String> availableDiskControllers = diskControllerMappingDao.listForHypervisor(HypervisorType.VMware).stream().map(DiskControllerMappingVO::getName).collect(Collectors.toList()); | |
| List<String> availableDiskControllers = diskControllerMappingDao.listForHypervisor(HypervisorType.VMware).stream() | |
| .map(DiskControllerMappingVO::getName) | |
| .sorted() | |
| .collect(Collectors.toList()); |
Copilot uses AI. Check for mistakes.
| if (currentBusName.startsWith(mapping.getBusName())) { | ||
| logger.debug("Choosing disk controller [{}] for virtual machine [{}] based on current bus name [{}].", mapping.getName(), vmMo, currentBusName); | ||
| return mapping; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
[nitpick] Falling back silently to an arbitrary existing controller may be confusing in failure scenarios. Add a debug or warning log here to record which controller was chosen and why the bus name lookup failed.
| } | |
| } | |
| logger.debug("Falling back to an arbitrary existing disk controller for virtual machine [{}] as no matching controller was found based on the current bus name.", vmMo); |
Copilot uses AI. Check for mistakes.
|
@blueorangutan test keepEnv |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-13478)
|
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Description
This is a refactor of the disk controller related logic for VMware that also adds support for SATA and NVME controllers.
A detailed description of these changes is available at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Disk+Controller+Mappings.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
How Has This Been Tested?
The tests below were performed for VMs with the following
rootDiskControlleranddataDiskControllerconfigurations:osdefault/osdefault(converted tolsilogic/lsilogic)ide/idepvscsi/pvscsisata/satanvme/nvmesata/lsilogicide/osdefaultosdefault/ideVM deployment: I deployed one VM with each of the configurations. I verified in vCenter that they had the correct amount of disk controllers, and that each volume was associated to the expected controller. The
sata/lsilogicVM was the only one that had a data disk; the others only had a root disk.VM start: I stopped the VMs deployed in (1) and started them again. I verified in vCenter that they had the correct amount of disk controllers, and that each volume was associated to the expected controller.
Disk attachment: while the VMs were running, I tried to attach a data disk. All the data disks were attached successfully (expect for the VMs using IDE as the data disk controller, which does not allow hot plugging disks; for these, I attached the disks after stopping the VM). I verified that all the disks were using the expected controller. Then, I stopped and started the VM, and verified that they were still using the expected controllers. Finally, I stoped the VMs and detached the volumes. I verified that they were detached successfully.
VM import: I unmanaged the VMs and imported them back. I verified that their settings were infered successfully according to the existing disk controllers. Then, I started the VMs, and verified that the controllers and the volumes were configured correctly.
The next tests were performed using the following imported VMs:
osdefault/osdefaultide/idenvme/nvmesata/lsilogicVolume migration: I migrated the volumes from NFS to local storage, and verified that the migration finished successfully. Then, I started the VMs and verified that both the controllers and the disks were configured correctly.
Volume resize: I expanded all of the disks, and verified in vCenter that their size was changed. Then, I started the VMs and verified that both the controllers and the disks were configured correctly.
VM snapshot: I took some VM snapshots, started the VMs and verified that everything was ok. I changed the configurations of the VM using
osdefault/osdefaulttosata/sataand started the VM to begin the reconfiguration process. I verified that the disk controllers in use were not removed, and that the disks were still associated with the previous controllers; however, the SATA controllers were also created. The VM was working as expected. Finally, I deleted the VM snapshots.Template creation from volume: I created templates from the root disks. Then, I deployed VMs from the templates. I verified that all the VMs had the same disk controllers as the original VM, and that the only existing disk was correctly associated with the configured root disk controller.
Template creation from volume snapshot: I took snapshots from the root disks, and created templates from the snapshots. Then, I deployed VMs from the templates. I verified that all the VMs had the same disk controllers as the original VM, and that the only existing disk was correctly associated with the configured root disk controller.
VM scale: with the VMs stopped, I scaled the VM from Small Instance to Medium Instance. I verified that the offering was changed. I started the VMs, and verified that the VMs were correctly reconfigured in vCenter.
Other tests:
System VM creation: after applying the patches, I recreated the SSVM and the CPVM. I verified that they were using a single LSI Logic controller. I also verified the controllers of a new VR and of an existing VR.
I attached 3 disks to the
ide/idecontroller. When trying to attach a 4th disk, I got an expected exception, as the IDE bus reached the maximum amount of devices (the 4th one was the CD/DVD drive).I removed all the disks from the
sata/lsilogicVM. I tried to attach the root disk again, and verified that it was attached successfully. I started the VM, and verified that it was configured correctly.I attached 8 disks to the
pvscsi/pvscsiVM, and verified that the 8th disk was successfully attached to device number 8 (device number 7 is reserved for the controller).