How long before refreshing Linked Clone or Instant Clone VM's

[mwyman]

I'm looking for some VMware documentation about the recommended or "best practice" for how long to keep a linked clone or instant clone VM around before either refreshing or deleting/recreating.

Does anyone know of where I can find this documentation?

I am looking for something straight from VMware because in my current env we have users logged into the same VM for 5 to 7 days before getting a new one. There are issues that the users have that are direct contributing factors to this and I am looking to change the way my company looks at virtual desktops. In other words, they think a virtual desktop is just like a physical machine in a sense where "I can have it on all the time and everything will be fine".

I know that it's highly recommended that clones vm's are only to be used for 48 max in most cases because of the page file/OS disk filling up and causing issues. Cloned vm's were never created to be left around for very long at all. I need some sort of documentation that proves what I'm trying to say that I can give to the right people to start making this change.

Any help is appreciated.

[jasonngtengpo]

Im not sure if there is such document, but I can share with your on my experience that It really depends on your company policies. I had seen many company adopted Horizon using either linked clones or instant clones. And all of them have different policies implemented. When i mentioned about policies is about your company's IT policies direction. Not the Horizon features.

For example...

1. some companies want to refresh the user's virtual desktops upon log off (or logoff after disconnect by XXX minutes) to avoid stuff like malware (wannacry). if you have NSX with microsegmentation will be even better. So when the user gotten this malware, the user just logs off and hope on to another floating virtual desktop. Or a new provisioned desktop. So they want to do this everyday for security reasons.
2. Another angle is looking at storage space efficiency. When you spin up a virtual desktop for the first time, that will be your minimum space usage. As when time goes by, the virtual desktop disk space starts to grow which contributed by many factors. Cache, user download stuff, OS patches and etc.

And lastly and I should say the most important, is educating. Some users don't like it and compare it to physical desktop or laptop. Some users are not IT or Computer savvy and thats why they could not understand. Therefore, you will need to explain to them the importants of "not leaving it on all the time". You probably need to do an onboarding training to the users.

[Shreyskar]

Hi M_W_

Starting Horizon 7.9, instant clones now supports delaying desktop refresh (however not recommended). But in special scenarios based on your use-case, you can delay it. Below is the doc:

Machine Refresh Operations

For your other queries refer Instant-Clone Desktop Pools

[bjohn]

I have seen many blogs say that selecting "never refresh" for Instant Clones is not recommended by VMware. Is there an official VMware document that states that?

Thank You

[hkraaijeveld]

Is there maybe a reason for the users wanting to be able to work this way? Have they been properly informed? Are there some persistence issues that make them do what they do? Is something not working the way it's supposed to for them? Do the functional requirements fit what has been built as to what it provides and how it's supposed to do it?

Cloned vm's are usually meant to be short-lived and non-persistent, as to facilitate the fact they remain the same, granting a similar experience every time you log on to one randomly. It also saves you a ton of storage and can scale up and down very fast in terms of available desktops. It can be easily made highly available and redundant as well.

Dedicated VM's can be managed differently, but cost more storage, but make persistence much easier. Recoverability changes a lot in this scenario as well, as does having desktops highly available, as this is usually a hard user to vm mapping.

Honestly, I think you don't need to prove them something, you need to get them onboard for the right reasons.