DaanHoogland commented on PR #13773: URL: https://github.com/apache/cloudstack/pull/13773#issuecomment-5267886437
> Hi @DaanHoogland, > > I've opened **#13857** against `main` with a more comprehensive workaround for the same issue (#13249): > > * Restores the classic worker-VM-based VMDK data-disk lifecycle on VMware 8 (removes the `VirtualStorageObjectManagerMO`/FCD path for data disks). > * Migrates root-level (deprecated) and `fcd/`-base-folder VMDKs into the VM default folder via `VirtualDiskManagerMO` during `attachVolume`, instead of going through the vCenter HTTP datastore browser for a locked file of a running VM. > * Maps CloudStack `ProvisioningType` → vSphere `VirtualDiskType` (`THIN/SPARSE/FAT`) and skips the VMDK adapter-descriptor update when the sync already migrated the disk. > > This supersedes the minimal "make updating the vmdk descriptor optional" guard in this PR — #13857 makes that guard unnecessary because the descriptor is no longer touched via the datastore browser at all on the affected path. > > Since #13857 targets `main` and this one targets `4.20`, there's no direct merge conflict, but we probably want to align on one approach before backporting. Happy to coordinate — would you prefer to: > > 1. Land [vmware: restore legacy VMDK data disk lifecycle (attachVolume HTTP 500 on VMware 8) #13857](https://github.com/apache/cloudstack/pull/13857) on `main` and cherry-pick the whole thing to `4.20` (superseding this PR), or > 2. Keep your minimal guard on `4.20` and take the fuller fix only on `main`? > > cc @rohityadavcloud @weijunster @H-LK , I would rather rebase your PR on 4.20 and abandon this one completely. still need to review it, but your description sounds sane. -- 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]
