Home > Blogs > VMware Consulting Blog > Monthly Archives: September 2016

Monthly Archives: September 2016

How to Add a Linux Machine as PowerShell Host in vRO

By Spas Kaloferov

Introduction

In this article we will look into the alpha version of Microsoft Windows PowerShell v6 for both Linux and Microsoft Windows. We will show how to execute PowerShell commands between Linux , Windows, and VMware vRealize Orchestrator (vRO):

  • Linux to Windows
  • Windows to Linux
  • Linux to Linux
  • vRO to Linux

We will also show how to add a Linux PowerShell (PSHost) in vRO.

Currently, the alpha version of PowerShell v6 does not support the PSCredential object, so we cannot use the Invoke-Command command to programmatically pass credentials and execute commands from vRO, through a Linux PSHost, to other Linux machines, or Windows machines. Conversely, we cannot execute from vRO –> through a Windows PSHost –> to Linux Machines.

To see how we used the Invoke-Command method to do this, see my blog Using CredSSP with the vCO PowerShell Plugin (SKKB1002).

In addition to not supporting the PSCredential object, the alpha version doesn’t support WinRM. WinRM is Microsoft’s implementation of the WS-Management protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that enables hardware and operating systems from different vendors to interoperate. Therefore, when adding a Linux machine as a PowerShell host in vRO, we will be using SSH instead of WinRM as the protocol of choice.

The PowerShell v6 RTM version is expected to support WinRM, so we will be able to add the Linux PSHost with WinRM, and not SSH.

So, let’s get started.

Continue reading

The Anatomy of an Instant Clone

By Travis Wood

If you’ve used Horizon View over the last few years, then you most likely have come across linked clones. Linked clones use a parent image, called a “replica,” that serves read requests to multiple virtual machines (VMs), and the writes in each desktop are captured on their own delta disk. Replicas can also be used to change desktop update methodologies; instead of updating every desktop, you can update the parent image and recompose the rest of the desktops.

Horizon 7 has introduced a new method of provisioning with Instant Clones. Instant Clones are similar to linked clones in that all desktops read from a replica disk and write to their own disk, but Instant Clone takes it one step further by doing the same thing with memory. Instant Clones utilize a new feature of vSphere 6 where desktop VMs are forked (that is, Instant Clones are created) off a running VM—instead of cloning a powered-off VM—which provides savings for provisioning, updates, and memory utilization.

Golden Image

With Instant Clones you start with your golden image, in a way that is similar to linked clones. The golden image is the VM you install the operating system on, then join to the domain, and install user applications on; you follow the same OS optimizations procedures you would use for Instant Clones.

When you’re done, release its IP address, shut it down, and create a snapshot. Now you are ready to create your Instant Clone desktop pool. This VM should have VM Tools installed, along with the Horizon Agent with the Instant Clone module. It is NOT possible to have the Instant Clone and Composer modules co-installed, so you will always need different snapshots if using Instant Clones and linked clones from the same golden image. Reservations can be set on the golden image and they will be copied to the Instant Clones, reducing the size of the VSwap file. It is important to note that the golden image must be on storage that’s accessible to the host you are creating your Instant Clone desktop pool on.

Template

When you create your pool, Horizon will create a template. A template is a linked clone from your golden image, created on the same datastore as the golden image. It will have the name cp-template, and will be in the folder ClonePrepInternalTemplateFolder. Template disk usage is quite small, about 60 MB. There will be an initial power-on after the template is created, but it will then shut off.

TWood_Horizon Template

Replica

Next, Horizon will create a replica, which is the same as a Linked Clone replica. It is a thin-provisioned, full clone of the template VM. This will serve as the common read disk for all of your Instant Clones, so it can be tiered onto appropriate storage through the Horizon Administrator console, the same way it is done with Linked Clones. Of course, if you are using VSAN, there is only one datastore, so tiering is done automatically. Horizon will also create a CBRC Digest file for the replica. The replica will be call cp-replica-GUID and will be in the folder ClonePrepReplicaVmFolder. The disk usage of the replica will be depend on how big your Gold Master is, but remember, it’s thin provisioned and not powered on, so you will not have VSwap functionality.

TWood_Horizon Replica

Parent

Horizon will now create the final copy of the original VM, called a parent, which will be used to fork the running VMs. The parent is created on every host in the cluster; remember, we are forking running VMs here, so every host needs to have a running VM. These will be placed on the same datastore as the desktop VMs, where there will be one per host per datastore. Because these are powered on, they have a VSwap file the size of the allocated vMEM. In addition, there will be a small delta disk to capture the writes booting the parent VM and the VMX Overhead VSwap file, but this—and the sum of the other disks—is relatively small, at about 500 MB. These will be placed in ClonePrepReplicaVmFolder.

TWood_Horizon Parent

Something you’ll notice with the parent VM is that it will use 100% of its allocated memory, causing a vCenter alarm.

TWood_vCenter Alarm

TWood_Virtual Machine Error

Instant Clones

OK! At this point, we are finally ready to fork! Horizon will create the Instant Clones based on the provisioning settings, which can be upfront or on-demand. Instant Clones will have a VSwap file equal to the size of the vMEM—minus any reservations set on the Gold Master, plus a differencing disk.

The amount of growth for the differencing disk will depend on how much is written to the local VM during the user’s session, but it is deleted on logout. When running View Planner tests, this can grow to about 500 MB, which is the same as when using View Planner for Linked Clones. The provisioning of Instant Clones will be fast! You’ll see much lower resource utilization of your vCenter Server and less IO on your disk subsystem because there is no boot storm from the VMs powering on.

TWood_vCenter Server

Conclusion

Instant Clones are a great new feature in Horizon 7 that take the concept of Linked Clones one step further. They bring the advantages of:

  • Reducing boot storms
  • Decreasing provisioning times
  • Decreasing change windows
  • Bringing savings to storage utilization

Instant Clones introduce a number of new objects: replicas, parents, and templates. It is important to understand not only how these are structured, but also their interrelationships, in order to plan your environment accordingly.


Travis is a Principal Architect in the Global Technology & Professional Services team, specializing in End User Computing.  He is also a member of the CTO Ambassadors program which connects the global field with R&D and engineering.