Does anyone knows when vSphere version 8 Update 2 will be supported?
Best answer by wgrande 30 November 2023, 13:57
I’ll check on this - generally the minor releases work out of the box (i.e we’re using VDDK 8.0 to support vSphere 8.0 U1 at the moment). But I’ll see if there is a target for official support.
Commvault is at the end of our validation process of 8.0.2, and I expect it to be announced as certified when we make our platform release announcements Mid-Dec 2023. However, from what I’ve seen, its going to be supported on Commcells running on CPR2022E and newer platform releases...
However, for future reference, it's not a matter of “Support” but of certification through our in-depth testing process. If you were to upgrade today to 8.0.2, Commvault will always be there to support you if it's in Commvault’s power to workaround any issues you may face within a VMware release. We’d look to evaluate and pivot a product enhancement where possible, but I’d personally not be able to comment on any turnaround times, as I don’t write code 😁. However, if it's not within Commvault’s powers, we’d always support our customer even if it additionally requires VMware’s assistance for the issue to be addressed from their side and coding as well.
Thank you for your answers. again Mid-Dec 2023.
For thread awareness… The Documentation page was meant to be updated to include stated certification for VMware 8.0.2. However, it was missed and is going to be actioned for change with priority.
Regarding VMware 8.0.2, please note that VMware announced a CBT issue on their side to be aware of under this kb article, https://kb.vmware.com/s/article/95940. This issue could result in VMware's CBT feature losing track of data changed on the VMDK when the disk is hot-extended. They will be addressing it within ESXi 8.0p03 and 8.0u3.
Commvault has an existing CBT validation check in place within the product to reset CBT in specific situations. However, it is currently being reviewed to determine if it addressed the uniqueness of this VMware bug.
It's currently suggested to transition to a Full Backup schedule compared to leveraging Synthetic Fulls until the advanced detection feature can be confirmed to cover the CBT reset for specific VMDKs only. If you're otherwise unable to modify the scheduling, it's recommended to investigate within VMware reports for VMs that have had VMDK sizes extended while on 8.0.2. If you locate a specific VM, you should perform a Full of just that VM. This process should continue until we complete the validation of the CBT validation feature and report an update here (or in other locations.)
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.