VMware has fixed the issue with vmfs6 and Windows 10/2019 Build 1809 on vSphere 6.5 and 6.7,
BUT the Fix will on the market with the next major release first, will comming out End Q2!!!
We'll get a Hotpatch for vSphere 6.5, but still have to wait for this 6 - 8 weeks );-(.
Hotpatch was delivered just two hours ago,
In my Lab Systemes on vmfs6 are now nearly so quick then systems on vmfs5, not perfekt but much better.
Now planing to roll out the Hotpatch on small plattforms to see whats happens.
Glad to know! Next Monday I will try also and check if my problem was solved.
Thanks for the reply.
Were do we find this hot patch?
X2, where can I download the patch from and is there a patch ID?
vCenter - 6.7.0 10244857
vSphere - 6.7 10302608
VMFS6 - 8 Snapshots - Windows 10 1809 - Boot time 8-9 Minutes
VMFS5 - 8 Snapshots - Windows 10 1809 - Boot time - 40 Seconds
Following thread and waiting for hot fix.
this Hotpatch (not Hotfix) is not public, its only deliviered to us, cause it was made based on our SR and logs.
But this Hotpatch will come in 6.5 U3 End Q2 on the market for public.
Ask by VMware maybe the will give you this Hotpatch too.
I opened a ticket and my support rep is giving me the run around regarding obtaining the hotpatch. To make things worse, I just patched all my ESXi hosts and now the issue seems to be worse
1809 VM on a VMFS6 datastore takes 51 minutes to boot up (prior to patching it was 6 minutes)
1803VM on same datastore takes 21 seconds.
It's now become unusable. This is not production (yet) but I don't want to wait until end of Q2 for the fix if a hotpatch exists.
We are just going to stick with VMFS5 as we don't see any benefit of VMFS6 in our environment. Since you are not in production, I would give that shot.
A patch for 6.7 might take even longer (like towards Q3 or Q4 2019) if what I'm being told is correct. The more people complain, the better the chances of getting it sooner i suppose. A hotfix exists for 6.5 but not sure if they have one for 6.7 but I think it depends on the build you're running anyway. Once you apply the hotfix, you can't apply normal vmware patches on top of it I think.
I opened an SR today and was told that there is no hotfix, and the hotfix that was available was pulled. The tech said I have to wait for U3 which is supposed to be released by the end of Q2. I don't know how my users can wait that long.
All of my datastores are VMFS5 and they have the slow boot issue.
We are experiencing the same issue on an ongoing project on vSphere 6.7 11675023 and VMFS.
Windows 10 1809 as master image for Instant Clones and QA VMs
Horizon 7.7, AppVolume 2.15. UEM 9.6, NSX 6.4.4, the whole package
Boot time are about on average to get the logon screen
EFI + 0 Snap = 20s
EFI + 1 Snap = 2m11 to 5-10m
Opened an SR with VMware
Could it be the Windows 10 Task to defrag and trim/unmap causing this? Noticed that after creation of the first snapshot that boot times do not increase right away, example from 20s to about 40s but after running the task manually then now boot time jumped into the minutes range.
It's not related to defrag. The lenth of time it takes to boot seems related to the number and/or size of the snapshot(s).
When you ran defrag the snapshot grew so your next reboot took a long time.
I was told there is supposed to be a KB coming out within the next week or two but it's not going to tell us anything we don't know. From what I was told, the fix for 6.7 is going to be out later than 6.5. Hopefully vmware will release it sooner though.
For VDI users this might be fixed via an update to some component of Horizon View and you may not have to wait for an updated ESXi version. I don't use VDI so don't know any more than that.
Out of interest guys - How are you finding the performance once the VM's have booted up? - I'm finding both Server 2019 and Windows 1809 (with the latest updates) are sluggish opening up explorer, settings menu etc.
Also - seamless apps published through a Citrix Server 2019 VDA are also a lot more sluggish in comparison with my 2012 R2 VDA's.
This is official response from VMware about this issue.
I've analyzed your issue and could see that this is a known issue that has been already identified and has been informed to our Engineering team.
The issue is identified to be due to some guest OS behavior change in this version of windows 10, 1809 w.r.t thin provisioned disks and snapshots, this has been confirmed as a bug and will be fixed in the following releases - 6.5 U3 and 6.7U3, which will be released within End of this year (2019).
Please let us know if you have any further queries.
They are basically saying that we cannot upgrade to 1809 this year and have to wait next release