I was having a conversation with one of our tech support guys (Greg Williams) recently about the relaxation on the requirement to allow Raw Device Mappings (RDMs) to be presented to different hosts using different SCSI identifiers and still do vMotion operations in vSphere 5.5. You can read that post here where I described how the restriction has been relaxed. Greg mentioned that he was handling a case where customers wished to share a physical mode/passthru RDM between VMs on different ESXi hosts with a view to running Microsoft Clustering Services (MSCS) on top. We call this CAB or Clustering Across Boxes.
I thought it might be useful to share some of the various VM Storage Policy status that I have observed whilst testing Virtual SAN (VSAN). I’m sure this is by no means a complete list but as I said, these are the ones that I have come across and I am sure these are the status that you will observe most often too.
Continuing on my set of posts related to Virtual SAN (VSAN) interoperability, let’s take a look at how vCenter Operations Manager (vC Ops for short) integrates with Virtual SAN. vC Ops version 5.8, which was released in December 2013, recognizes the VSAN datastore and can report various characteristics, as you might expect. Although vC Ops 5.8 was released around 3 months before VSAN GA’ed, this release works with ESXi 5.5U1 and vCenter 5.5U1, the vSphere release which introduced VSAN. However, this release of vC Ops does not present all the ‘storage’ metrics for VSAN like it does for datastores based on other storage types. But, having said that, there are still a number of useful vC Ops views and metrics that you might find useful which this post will cover.
At this stage, VSAN has only been in GA for a number of weeks, even though many of us here at VMware have been working on it for a year or two (or even more). Sometimes when we get into explaining the details of storage objects, components, etc, we forget that this is all so new for so many people. In a recent post, someone asked me to explain the concept of a witness on VSAN. Looking back over my posts, I was surprised to realize that I hadn’t already explained it. That is the purpose of this post – explain what a witness disk is in VSAN, and what role it provides.
In a previous post I spoke in-depth about the different objects which go to make up a virtual machine which resides on a VSAN datastore. To recap, these are the VM Home Namespace, the VM Swap, the VMDK objects and the snapshot delta objects. Now, VMDKs comply with the full set of rules that are placed in a VM Storage Policy and applied to a virtual machine. Snapshot deltas inherit the same VM Storage Policies as their VMDK base disk and also comply with the full set of rules in the VM Storage Policy – so far so good. VM Home Namespace is a little different – its behaviour and which capabilities it complies with are discussed in this earlier article. This leaves the VM Swap object, and that is what I plan to cover in this article.
In my new role, I get to work with a lot of new products and features that are not yet in a state to be used for beta, never mind being close to GA. This means, from time to time, that we needs to work around a few specific problems to get the product/feature to work. On this particular occasion, we were trying to add a custom firewall rule to an ESXi host. The rule took fine, but did not persist through reboots of the ESXi host, which is what was required. This is the solution we came up with.
While running through a bunch of interoperability tests for VSAN, one of the products I deployed was VMware View 5.3.1. This required a bunch of virtual machines to be rolled out; one VM for my SQL Server database to support View Composer, another for View Composer itself and then finally another VM for View Connection Server (also known as the connection broker). It was during the install of View Connection server that I hit this issue:
Error 1720: There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Customer action VM_AdamLoadVdiSchemaPreReqs script error -2147024894, : Line 16, Column 1,