I already wrote an article on the NexentaConnect for VSAN product after seeing it in action at VMworld last year. More recently, I had the opportunity to play with it in earnest. Rather than giving you the whole low-down on NexentaConnect, instead I will use this post to show the steps involved in presenting a file share built by NexentaConnect to a VM. In this case, the VM and the file share both reside on Virtual SAN. I will also show you how to simply revert to a point-in-time snapshot of the file share using NexentaConnect. To answer the common question, “can VSAN do file shares as well as storing virtual machines?”, the answer is yes. This post will show you how.
I’ve had an opportunity recently to get some hands-on with HyTrust’s Data Control product to do some data encryption of virtual machine disks in my Virtual SAN 6.0 environment. I won’t deep dive into all of the “bells and whistle” details about HyTrust – my good buddy Rawlinson has already done a tremendous job detailing that in this blog post. Instead I am going to go through a step-by-step example of how to use HyTrust and show how it prevents your virtual machine disk from being snooped. In my case, I am encrypting virtual machine disks from VMs that are deployed on VSAN, as I have had this question in the past, i.e. can VMDKs on VSAN be encrypted? The answer is yes. This post will show you how.
Is it just me, or does VMworld seem to come around quicker these days? Anyway, it is great to have a couple of sessions in again this year, and yes – you guessed it, these are VSAN sessions once again.
STO4572 – Successful Virtual SAN Evaluation/Proof-Of-Concepts
This is an update on last year’s VSAN Proof-Of-Concept talk. A lot has changed in the last year, and the idea of this session is to fill you in on all the potential gotchas that you might encounter when trying to evaluate VSAN. I’ll be co-presenting this with Julienne Pham of VMware who has built up a wealth of field experience on VSAN. We’ll cover everything you need to know, including how to conduct various failure scenarios, and get the best performance. Thinking about deploying VSAN? This is one not to miss.
Regular readers will know that I normally blog about the technical aspects of storage, as opposed to doing opinion pieces. However there have been a number of articles published recently questioning the value of VMware’s Virtual Volumes, commonly referred to as VVols. In general, the pieces I have read ask whether or not VVols (or to be more accurate, per-VM granularity feature of VVols) adds value when NFS is already doing per-VM granularity in the form of files. The point that was missed in these pieces is that VVols is so much more than per-VM granularity. I’ve just come back from some great VMUG events in Frankfurt, Germany and Warsaw, Poland where I presented on the value of VVols to our users. I therefore thought it opportune to post about the other benefits of virtual volumes.
Virtual SAN already has a number of features and extensions for performance monitoring and real-time diagnostics and troubleshooting. In particular, there is VSAN Observer, which is included as part of the Ruby vSphere Console (RVC). Another new feature is the Health Check Plugin, which was recently launched for VSAN 6.0. However, a lot of our VSAN customers are already using vRealize Operations Manager, and they have asked if this could be extended to VSAN, allowing them us to use a “single pane of glass” for their infrastructure monitoring. That’s just what we have done, and the beta for the vROps Management Pack for Virtual SAN is now open. You can sign up by clicking here.
Earlier this month, I shared a post about my experiences with deploying VIO, VMware integrated OpenStack. One of the issues I highlighted was the fact that when I tried to create a network, it failed with a very unhelpful error message. The reason the network creation failed was due to a limitation with using a distributed switch (VDS). Instead I had to create what was known as a “provider network”, which is a special step needed for VDS networking. I am in the midst of an OpenStack training, and I’m trying to relate what I am learning on the training class to my VIO deployment. What I’m finding is that there are a number of limitations when using VIO with a distributed switch, which is making it difficult to try out some of the concepts and lab exercises covered in the training class.
I hadn’t realized that we had now begun to use the LVM (Logical Volume Manager) in our vCenter Server Appliance (VCSA) version 6.0. Of course, I found out the hard way after a network outage in our lab brought down our VCSA which was running on NFS. On reboot, the VCSA complained about file system integrity as follows: