My good pal Paudie and I are back in full customer[0] mode these past few weeks, testing out lots of new and upcoming features in future release of vSAN. Our testing led us to building a new vSAN stretched cluster, with 5 nodes on the preferred site, 5 nodes on the secondary site, and of course the obligatory witness node. Now, it had been a while since we put vSAN stretched cluster through its paces. The last time was the vSAN 6.1 release, which led us to create some additional sections on stretched cluster for the vSAN Proof Of Concept…
This is something very interesting which gained support with the release of vSAN 6.5. It will be of interest to those customers who boot their ESXi hosts from USB/SD devices, and also have vSAN configured. One long-standing restriction with this configuration was the inability to boot from USB/SD when the amount of memory in the host is over 512GB. This is because we could not guarantee that the memory dump would fit in the pre-sized core dump partition. Well, now we have the ability to resize the core dump partition, even when it resides on a USB/SD device. The guidance…
I mentioned in a previous post that we have recently released Photon Controller version 1.1, and one of the major enhancements was the inclusion of support for vSAN. I wrote about the steps to do this in the previous post, but now I want to show you how to utilize vSAN storage for the orchestration frameworks (e.g. Kubernetes) that you deploy on top of Photon Controller. In other words, I am going to describe the steps that need to be taken in order for these Kubernetes VMs (master, etcd, workers) to be able to consume the vsanDatastore that is now…
Many of you will have seen the recent announcement for Photon Controller version 1.1. For me, the interesting part of this announcement is the support for vSAN as a storage platform with Photon Controller v1.1. I should think that the first question that those of you are familiar with both vSAN and Photon Controller will ask is “how do I configure vSAN for Photon Controller when there is no vCenter server in the mix?”. This is a very good question, and one which I will highlight in this blog post. There are also a few line items in the release…
The first email I saw this morning in my inbox was from my good pal, Alan Renouf. Alan is our product line manager for APIs, SDKs, CLIs and Automation Frameworks (congrats on the promotion Alan). Anyway, Alan was announcing the General Availability of VMware vSphere PowerCLI 6.5 Release 1. There are a whole bunch of improvements in this release, and much kudos must go to the PowerCLI team. However from a vSAN perspective, things look really cool. [Update] This version of PowerCLI also works with vSAN 6.2 and 6.0, so there is no need for customers to upgrade to vSAN…
The answer is an emphatic yes. One can absolutely use storage policies with vSphere Integrated Containers (VIC). However, there is currently no way to specify a policy at the docker CLI when creating a container (at this time). Therefore one would have to deploy the VCH, then deploy the container, and then finally modify the storage policy as appropriate. My understanding is that consideration is being given to a way to do this at deployment time, but at the present, it involves a number of steps. Let’s discuss them in turn.
I know that there will be a lot of information coming your way from various sources on this exact topic. Obviously, I would urge you to check out the latest and greatest documentation from our technical marketing guys for deeper detail and “how-to” guides. However, I did want to provide a brief overview of what new VSAN features are available in vSphere 6.5. Note that we also refer to this version of VSAN as 6.5.