sureshanaparti commented on PR #9433:
URL: https://github.com/apache/cloudstack/pull/9433#issuecomment-2309348283

   > > > 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.
   
   @winterhazel The data disk controller is matched with the SCSI root disk 
controller only when the data disk controller is not set in the VM's template 
and VM detail. If template has the root and data disk controllers set to 
_pvscsi_ and _osdefault_ respectively, then the controllers are created with 
_pvscsi_ controller to ensure root disk is configured to proper controller to 
create the VM. Later, any unsupported data disk controller (say, _lsilogic_) 
set would fail the attach disk, so the operator should ensure to set the root 
and data disk controller appropriately.
   
   As the controllers are already created during the VM creation process, it's 
better to synchronize these controller details during VM creation. 
Synchronizing in the attach process would still set the same controller details 
(if you mean dynamic reconfiguration of disk controllers in VM, maybe the 
existing controller reconfiguration based on the data disk controller can be 
done as a separate improvement later). The changes here would fix the attach 
issue when data disk controller is not set in the VM's template and VM detail.


-- 
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]

Reply via email to