winterhazel commented on PR #9433: URL: https://github.com/apache/cloudstack/pull/9433#issuecomment-2307668260
> > I have not tested in a VMware environment to confirm, but is this really fixing the issue when attaching a volume? The volume attach workflow does not seem to use the changed code. > > From what I could gather by reading the code, the problem happens because CloudStack tries to attach the data disks using default SCSI controllers (LSI Logic), but there are only PVSCSI controllers. I think that changing the data disk controllers to LSI Logic (while having PVSCSI root disk controllers) and trying to attach a data disk should still produce the same error. > > If that is the case, maybe it would be good to prioritize using the root disk controllers for data disks on the volume attach workflow in case both are SCSI? > > All the disk controllers in VMware VM are created using the same type mentioned in root disk controller (primary controller), so the data disk controller should match with that controller type created to support attach data volume. If data disk controller has a different controller type, attach fails as it is not found in the VM spec. > > In this case, when data disk controller is not set, previously it was set to osdefault, which picks the default controller type (say, lsilogic) for that OS and might not be the same as root disk controller (say, pvscsi). so, it's better to sync the data disk controller (when not set) with root disk controller. I understand that you want to synchronize the data disk controller with the root disk controller to ensure data disks can be attached. However, I think that we are doing it in the wrong place. I think that it would be better to synchronize it in the volume attachment process itself. As you mentioned, if both root disks and data disks use SCSI controllers, the root disk controller is prioritized when creating a VM. So, suppose we have a scenario in which a template has `rootDiskController` set to `pvscsi` and `dataDiskController` set to `osdefault` or any other SCSI subtype (which is the current configuration for some existing VMs because `dataDiskController` defaulted to `osdefault` when not set): if we deploy a VM from that template with a data disk, the deployment process will prioritize using the root disk's controller (PVSCSI) for the data disk, even though `dataDiskController` may have been set set to something else, and the VM will be created successfully with two disks that use PVSCSI controllers. However, if we try to attach another volume to that VM (or detach and reattach the data disk), an exception will be thrown because the volume attachment process tries to attach the data disk using a LSI Logic controller instead. To avoid this exception for these scenarios as well, I think that it would be better to fix the original issue by making the volume attachment process consistent with the VM creation process: prioritizing the root disk controller in case both details are set to SCSI subtypes, instead of matching them when the VM is created only if `dataDiskController` is empty. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
