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,
It should come as no surprise but VMware Horizon View is also supported on VSAN. VMware released Horizon View version 5.3.1 to coincide with the vSphere 5.5.U1 and VSAN release. This release allows desktops to be successfully deployed on a VSAN datastore, using default policies for the desktop storage objects. Let’s go through the steps to get this configured and running, and then we can talk about the default policy settings afterwards.
In this post I though it might be useful to share some information about VSAN interoperability with VMware’s flagship backup and restore product, vSphere Data Protection also known as VDP. First a note about versions - that you will need to use the March 2014 release of VDP (version 5.5.6), not just to backup VMs running on VSAN, but to back up VMs running on vSphere 5.5U1. Here is a comment taken from the release notes for ESXi 5.5 U1:
- vSphere Data Protection. vSphere Data Protection 5.1 is not compatible with vSphere 5.5 because of a change in the way vSphere Web Client operates. vSphere Data Protection 5.1 users who upgrade to vSphere 5.5 must also update vSphere Data Protection to continue using vSphere Data Protection.
After spending a lot of time looking at the architecture of VSAN, I wanted to spend some time looking at how well it inter-operates with other vSphere products and features. vSphere Replication is a product which works quite well with VSAN. If you want to provide disaster-recovery using VSAN as a storage layer, you will need to use vSphere Replication version 5.5.1 which was released in March 2014. One thing with vSphere Replication is that it is agnostic to the underlying storage. Having said that, the consideration with using vSphere Replication with VSAN is down to the VM Storage Policies used by the virtual machines, and how these inter-operate.
Our team was recently asked to take a VSAN novice through a VSAN deployment, to figure out if there were any configuration gotchas. This post will share the stumbling blocks that you might encounter deploying your own VSAN environment.