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 –…
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…
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…
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…
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…