OverView Back in vSphere 5 a new VAAI primitive called unmap was released. When using thin provisioned volumes or LUNs for VMFS datastores, actions such as storage vMotion, consolidating snapshots and deleting data (such as VMDK files) do not automatically reclaim the space on the underlying datastore. For example, if you have a thin provisioned 1TB datastore that has 2 x virtual machines using 400GB each, and you delete one of these virtual machines (using the ‘delete from disk’ action), the used space on the datastore will still report as 800GB.

For my lab, I run everything nested within VMWare workstation, which is running on a single Dell physical host that runs Windows for the base OS. Over the past couple of months, I’ve been trying to spend a bit more time in the lab, mostly for learning some components of the vSphere environment I’m not familiar with, but also as a test area. I deliberately started the environment with a single embedded deployment, so the PSC and VC server was running on the one node.

Introduction As of vSphere 6.0U1, VMware allow an embedded vCenter server deployment to be reconfigured to an external deployment, which demotes the Platform Services Controller (PSC) components of the embedded node and points the VC server to an external PSC node which resides in the same Single Sign On (SSO) domain as the source embedded node. This is done by using the utility cmsso-util Before we get too much further, there are two main uses for cmsso-util:

In my lab, I deployed vCenter using the appliance as an embedded node using vCenter 6.0.0b. I purposely deployed this build, as an embedded deployment for two reasons: I haven’t used the appliance before, and I wanted the lab to be simple, but I also wanted to see the upgrade process in action on the appliance I wanted to deploy an external PSC and follow the process to re point the original VC server to the new external PSC, as outlined here: http://pubs.

I’m working on rolling out vCenter Host Profiles at work, to keep an eye on our configuration and also to assist in the deployment of new ESXi servers into our environment. If you haven’t checked out host profiles and you have a VMWare Enterprise Plus license, it is a must! I’m working through a few of our clusters that are connected to our Nimble Storage arrays using the iSCSI Software Initiator, and that use the Nimble Path Selection Policy (PSP) to determine the best path policies from the ESXi host to the storage.

I’m still getting my lab configured and I am planning on using Windows Server 2012 R2 as an iSCSI target (as well as an NFS server). The server in my environment is called Storage01. I’ve added 2 NICs to the machine, and was trying to figure out where to set the network binding for the iSCSI traffic. It wasn’t where I expected, and I couldn’t find much online, so I thought I’d write a quick note on it.

I manage an Exchange 2013 deployment at work which is configured in Hybrid with Office365. Recently we had to change our SSL certificate that was being used for both TLS for the hybrid connection and also for our client facing DNS names. Due to changes with our 3rd party SSL certificate provider, this was a new SSL certificate installation rather than a renewal. I generated the certificate and installed it onto all of the Exchange servers on-premises and during our change window, made the changes to bind the services to the new certificate and then ran the Hybrid connection wizard to update the certificate used in our On-Prem send connector to Office365 and also to the receive connector in our Office365 tenant.

So last week I noticed that a user by the name of Dean had opened a thread on the Nimble Connect forums with some handy PowerCLI to configure an ESXi host to connect to Nimble Storage arrays. I had done the same thing near the end of 2015 when we installed 6 Nimble Storage arrays in our environment, and I was meant to get around to putting it all together in a powershell function/script.

When setting up VMWare SRM 6.1 with array based replication, I was seeing an error after adding the array managers into SRM. The error was Duplicate initiator ‘iqn.1998-01.com.vmware:Server1-280206e1’ found in SRA’s ‘discoverDevices’ response. In the vmware-dr-xxx.log file found in C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs there was a tiny bit more info: 2016-01-13T09:39:10.757+11:00 [03508 info 'DrTask' opID=5cacf7dd] Task 'dr.storage.ReplicatedArrayPair.discoverDevices112' failed with error: (dr.storage.fault.DuplicateInitiator) { --> faultCause = (vmodl.MethodFault) null, --> command = "discoverDevices", --> responseXml = "<Initiator id="iqn.

I’m going through the process of installing VMWare Site Recovery Manager (SRM) 6.1 in our production environment, which is currently running vSphere 6.0U1. We use Nimble Storage arrays and have elected to make use of array based replication (ABR) for data replication between sites. During our initial testing and doing full failovers of some dev applications, I noticed that the datastore name within vCenter for the protected volume on the SAN was getting renamed, and had a prefix of snap-5b356a02-VolumeName