Thursday, February 24, 2022

Why we need to deploy Instant Clone?

It's highly recommended to use the Instant Clone Desktop Pool (IC-DP) in comparison to the Full Clone Desktop Pool (FC-DP). But why? You may think it's an easy question that has complex answers, but I believe it's vice versa because I believe it's not a simple question but can have many easy answers. In many projects I saw the network administrators think about creating full clones is a better choice than using Instant Clones, because it’s easier to deploy and manage. Regardless of this idea is true or not, I think before creating any type of desktop pool, we should plan carefully to understand which type of desktop is more suitable for our VDI environment and can answer our end-users demands. 

First of all, I should mention in comparison to the FC-DP, management operations related to the IC-DP including maintenance jobs, updating procedures, and running them as an orchestrated workflow are more reliable and more schedulable in the overall support duration. For example, consider a situation you want to update the Horizon Agent on all of the desktops that belong to an FC-DP. Which options we have?

1. Rebuild the whole desktop pool again with an updated template (reference template)? If you want to do it, updating the Agent of your Golden Image used on your IC-DP will take the same amount of time as  FC-DP, but honestly, as you know reconstruction of all desktops consumes a long time for FC-DP (Even maybe one hour, while it's about the seconds for IC-DP)
2. Update the existing desktops via scripting? If you run the Agent installation in the silent mode, and run it through a scheduled script or execute via a domain policy, I can answer Yes! it's a good method (I will teach how to do it, in another post). But keep in mind it's required to monitor carefully with more attention because you need to check the correctness of script execution, the Policy establishment, and checking the machine's section on the Horizon management console through all steps of this operation.

Let's back to where I explain the initial step, what will satisfy your company and its end-user? I want to conclude such as this: FC-DP is simpler to build but is not true for long-time maintenance actions Because IC-DP acts faster in rebuilding steps. Of course, I agree the construction of IC-DP requires more background preparation phases than the FC-DP. So, I described the following checklist based on my experiences in different situations. I think if you consider them before starting a new VDI project, it can be a great one:

1. Complete the Cluster configuration, before running the VDI construction: In some situations, you may still be in the process of ESXi cluster building and also shared storage implementation. If they are not completed yet or some hosts are not connected to the corresponding LUNs, then don't run the IC-DP deployment on them. Because in such as these circumstances, desktop deployment tasks will be failed. So you should ignore those hosts to a candidate as the VM (desktop) placement or remove them from the cluster totally until you fix the SAN connectivities. Also, you can balance the desktop's resource usage via enabling the DRS.

2. Assign Flash-based volumes as the VDI storage placement: If there is no SSD datastore inside your data center, never try IC-DP creation. Although the procedure of IC-DP deployment includes several objects (Master, Internal, Replica, Parent) and it's not simple as the way of FC-DP, you can satisfy of very fast-provisioning via implementing the flash-based disks because they are the best storage candidate for high-rate disk-reading workloads. The good news is if you need to multiple IC-DP there is no need to dedicated another VM/Snapshot combination and even the Connection Server do not deploy whole combination of mentioned prerequisites IC-DP's virtual machines (Parent is different).

3. Define a procedure to update the DP’s machines regularly: One of the important difference between the two types of desktop pools is the way of their future maintenance operations, like upgrading and patching the OS, updating the installed antivirus, installing new versions of required software, and so on. Instant Clones are the better choice for the VDI change management operations, because based on IC-DP architecture you can easily update the Golden Image and then re-deploy desktops again. (Keep its OS and Apps updated when the VM is power-on, then generate a new snapshot and just replace with the old one easily)

 

4. Less storage is required: IC-DP is based on JMS technology (like other VMware products such as App Volumes) and uses the virtual disks and memory of its Parent-VM. So, if you want to take these advantages in your environment, don’t lose the IC-DP. It's good to know you can keep and protect the user profiles by using VMware Workspace ONE UEM or  Microsoft SCCM OSD profile capturing feature especially whenever you plan to deploy persistent desktops. 

5. Identical organization requirements, means same workloads and truly same applications: Whenever your clients need to same Apps and Services, and a general perspective has been defined for access the organizational resources, IC-DP is the best option, especially for non-persistent desktops that you can refresh them without any user considerations. Kiosks and any other types of OS-less workstations that are connecting to the network through the Horizon  is another use-case for accepting them as the clients of IC-DP, because generally they are not dedicated to the users and are public devices in our organizations. 

VMware improves the Instant Clone technology, for example I guess there is no SID-duplication issue. I checked it in one of the IC-DP members through Windows Power-Shell:

Get-ADComputer  -filter  {name -like '*vdi*'} | fl name, sid, *guid  

Although there are still some considerations and restrictions for Instant Clone technology in each of Horizon View version as I mentioned some of them above. So keep in mind always extract the details of organization's requests from the considered VDI solution, then start to build your virtual desktop infrastructure.

 

Friday, February 18, 2022

VMSA-2022-0004

  Three days ago another critical vulnerability has been announced by VMware around CVE-2021-22040, CVE-2021-22041 that are about the virtual machine USB controllers that let the "malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host." All ESXi versions 6.x and 7.x and Fusion 12.x and Workstation 16.x are vulnerable against this exploit. Fortunately there is a released patch to fix the issue (for example ESXi7.0 Update 3c), although there is a workaround for the mentioned vulnerabilities too. If you need to read more information: VMSA-2022-0004

However there is an attached file in the link below that you can use to list all VMs with connected USB controller and also remove them automatically: KB87617.

 

I will start a new journey soon ...