I had another question recently about whether or not the Storage vMotion behaviour of renaming VM files on a VMFS or NFS datastore also worked with Virtual Volumes or VVols? After a quick test, I can state categorically that the answer is yes. I created a VM on a Nimble Storage appliance, presented two unique storage containers (aka virtual volume datastores), deployed a test VM on one of the VVol datastores, and then renamed the VM in the vSphere web client. I then verified that the VM name in the vSphere client was different to the names of its files…
Last week, I was presenting at the VMware User Group (VMUG) event in Poland. My topic was SPBM, Storage Policy Based Management. This is the framework for consuming data services, whether these are provided from vSAN, Virtual Volumes or VAIO (IO Filters). You can get the presentation from here. One of the attendees who had implemented Virtual Volumes (aka VVols) asked a very interesting question about changing policies of a VVol based VM on-the-fly. The question is whether a policy change causes a new VVol has to be instantiated, data synced to original VVol and then the original VVol is…
My Storage Policy Based Management (SPBM) presentation slide deck is now available online. This is the presentation that I delivered at a number of VMUG (VMware User Group) meetings this year in Europe, primarily Norway and Poland. SPBM is an integral part of VMware’s software defined storage vision, and is deeply integrated into vSAN, Virtual Volumes (VVols) and VAIO, the vSphere APIs for I/O Filters. Hope you find it useful. 2017 VMUG Storage Policy Based Management from Cormac Hogan
I was doing some work in the lab with Storage Policy Based Management recently. I was using both vSAN and a Virtual Volume array from Nimble Storage. While I was able to create independent policies for both vSAN and VVols, I was curious to see if I could create a policy where I could be offered both datastore types for the initial placement of a VM. For example, if I wanted to ensure my VM was encrypted, could I have a policy which would be compliant with both vSAN datastore and the Virtual Volume datastore, so long as they both…
With the release of vSphere 6.0 earlier this year, VMware introduced the eagerly anticipated VVols or Virtual Volumes. As we see more and more traction around VVols, a specific question has come up a number of times already. The question is basically: “What happens to VVols if I lose my VASA Provider or my vCenter Server, or indeed both of these components? Will I still have access to my devices?”.
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…
I had a very interesting query in my recent VVol post on vSphere HA interop. In that post I showed how the VVol datastore could be used for datastore heartbeating. The question then arose when the VVol datastore could be used for other things, such as a syslog and scratch destination. I couldn’t see any reason why not, but just to be sure, I tested it out in the lab. The quick answer is yes, you can use a Config-VVol for syslog, and no, you cannot use a Config-VVol for scratch. If you want to see the steps involved, and…