Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

After recreate vSAN disk Group with VDI link clone environment , re-balance or recompose need to be done on vSAN before VDI logout/deploying new desktop (76291)

Last Updated: 8/15/2023Categories: How toTotal Views: 3265Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Details

In a vSAN cluster with VDI environment, when you must replace a failed cache device you delete disk groups from a host or in situation where you end up re-creating complete disk group.

When you recreate a disk group in the host after rebuild finish there are no objects in a disk group and hence the DG is empty initially.

When user logout from Linked Clone desktop  the  "checkpoint.vmdk"  will be removed and recreated.
If there are no objects in the disk group of the host,  checkpoint.vmdk will be deployed to the newly created disk group of the host. As all the newly created checkpoint.vmdk will be created on new diskgroup, there is possibility of heavy IO burst on the disk group once user starts log in VDI environment causing the IO congestion.

Solution

We need to prevent IO burst going to single DG of vSAN that may cause by re-balance or recompose.
1. After you create new diskgroup, you should do a proactive re-balance immediately if possible and wait till it finishes to ensure data is distributed equally across diskgroup
It is good practice to finish the proactive load -rebalance before user logs in the VDI environment. You may refer below KB article for the proactive load re-balance .

vSAN proactive rebalance

Recompose operation in VDI environment will delete all checkpoint.vmdk for all VMs and recreate all checkpoint.vmdk for all VMs. After recompose operation,  all checkpoint.vmdk are deployed to all Disk Group and checkpoint.vmdk will be distributed across all disk group evenly and IO burst will not be limited to single diskgroup.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
データベースのフェイルオーバー イベント後に一部のサービスを復旧できない問題を解決するための vRA 8.0.0 HA 環境用のパッチ (76222)

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSAN

VMware Horizon

Related Versions:

VMware vSAN 7.0.x

VMware vSAN 6.x

VMware Horizon 7.x

VMware Horizon 7

Take Our Survey

Support Assistant