We've reached the first RC build milestone with Update 3a for Veeam Backup & Replication, which is the point when our QC starts to perform the final regression cycle, with the RTM build typically following in 10 to 15 days. Once that happens, the following 1-2 weeks we will be doing pilot deployments, as per our standard release process – with our support engineers reaching out to customers with support cases open on issues fixed in the update. This lets us track everyone who received the RTM build for an unlikely event of its recall due to the discovery of a major regression. I will announce the RTM build availability both here and on the forum, so that anyone else who wants to participate in the pilot could reach out to our support for the build. Below is a recap of new platform support situation in the Update 3a build to be shipped:
VMware vSphere 6.7 will be fully supported with no known issues or limitations from Veeam perspective. But those of you who like to be on the cutting edge with new vSphere functionality, please be aware that you won't be able to backup VMs with virtual NVDIMM devices present, or with virtual disks residing on PMem datastores. This is due to lack of VM snapshot support for such VMs in vSphere. But this should not come as a surprise, as it's quite traditional for VMware to release new functionality this way (remember no snapshot support for Fault Tolerant VMs originally).
VMware vSphere 6.5 U2 will NOT be officially supported with Update 3a due to the previously discussed vSphere API regression introduced by U2 and impacting environments with heavy host load. However, Update 3a does introduce "preliminary" U2 support by fixing all outstanding U2-specific issues (such as hot add transport failing with certain proxies), so in theory the newer U2 build fixing the API issue should be supported automatically – so long as it does not break something else, of course. And in general, Update 3a will make U2 "safer" to use in average (not heavily overprovisioned) environments which already upgraded to one. It's just that we are unable to support it officially, because any significant load spike will cause vSphere API to start failing randomly, consequently impacting most of the Veeam functionality. I will keep posting updates on VMware investigation of the API issue in the main topic about vSphere 6.5 U2 support.
VMware vCloud Director 9.1 support is also a part of Update 3a, at what we call "compatibility" level. This basically means that if you upgrade to the new platform version, everything you're doing today is guaranteed to continue working. But there are a couple of minor issues around new features introduced in vCloud Director 9.1 (specifically, with Standalone VMs and Guest vLAN Allowed option) which may require manual tweaks after full VM restore. These issues will be documented in the release notes for Update 3a.
Microsoft Hyper-V 1803, Windows Server 1803 and Windows 10 April 2018 Update will be fully supported with no known issues or limitations from Veeam perspective. Very few things were broken in these releases, so kudos to Microsoft for that. This was certainly not the case with previous releases – in fact so much that we even invested in developing a tool to compare WMI between latest and new OS versions! Well guess what – the very first time we actually used one in anger, it returned no changes!
We're also shipping the updated versions of Veeam Agents along with Update 3a - and normally, they would have followed the actual update schedule. However, given the outstanding major issue with RHEL 7.5 that I covered here a couple of weeks ago, we're intended to make the RTM build of Veeam Agent for Linux 2.0.1 available through our support sooner. The RC build has been in testing for a few days now, and the RTM build is expected this week. Our support engineers will start reaching out to everyone with support cases opened on this issue as soon as QC signs off the RTM build.
Short update on ReFS block cloning slowdown issues due to May Windows updates. We have already received and tested the private ReFS driver from Microsoft - and it does fix the issue, bringing block cloning performance back to normal. I have not received any estimations from ReFS dev team themselves yet as to when it will be shipped, but support engineer on the corresponding support case we've opened just for the record noted July 10 being the date. So not as fast as we all hoped – and probably too long to go without May updates installed, meaning the only good interim solution is to replace ReFS.sys with version 10.0.14393.2097 (the one from prior to installing May updates).
Finally, just to close the loop on VMware VVols data corruption issue that I've beein discussing here so much in the past months, the official VMware KB article is now live > VMs get corrupted on vVOL datastores after vMotion (55800) |
Komentáře
Okomentovat