This feature has many names. Creating a larger config vVol. Creating a sub-vVol datastore. Creating an ISO repository. Etc.
In 7.0U2, VMware added a new feature that supports creating a custom size config vVol–while this was technically possible in earlier releases, it was not supported. Also, I should note that this is not supported by all vVol vendors, so of course speak to your vendor first.
First to review what a config vVol is check out this post:
What is a Config VVol Anyways?
In short, it is a mini VMFS that gets created when you create a directory in a vVol datastore (most commonly created by creating a new VM). This defaults to 4 GB in size. Enough to store the general VM files; some logs, VMDK pointers, vmx file, and some other frivolities.
The issue though is that this was not large enough to store large things like ISOs or vib files or whatever. So if you tried to upload something to a vVol datastore folder it would fail with an out-of-space issue. And you cannot upload to the root of a vVol datastore because a vVol datastore is not a file system. So you had to use VMFS or NFS to store those objects.
This is no longer the case.
Continue reading “What’s New in vSphere 7.0 U2 Storage: Creating a File Repository on a vVol Datastore”
In this post, I will overview how to synchronize a VVol-based replication group with PowerCLI. See previous posts below for more context:
This post is somewhat specific to Pure Storage–the cmdlets of course are universal, but behaviors may not correlate to your storage array. So if you are using VVols on a non-Pure array, certainly consult your vendor.
Furthermore, this is certainly specific to PowerCLI when it comes to the commands. With that being said, the fundamentals on how this works with Pure is common for all orchestration tools, so you should be able to use this information for other tools. Though of course the cmds/syntax will be different.
Continue reading “PowerCLI and VVols Part VII: Synchronizing a Replication Group”
There are a variety of ways to assign and set a SPBM Policy to a VM. I recently put out a workflow package for vRO to everything VVols and Pure:
vRealize Orchestrator VVol Workflow Package
I also specifically blogged about assigning a policy to a VM with vRO:
Assigning a VVol VM Storage Policy with vRO
How do you do this with PowerCLI?
Continue reading “PowerCLI and VVols Part I: Assigning a SPBM Policy”
I recently did a VMUG webcast on VVols and there were a ton of questions and unfortunately I ran out of time and could not answer a lot of them. I felt bad about that, so I decided to follow up. I was going to send out emails to the people who asked, but figured it was simpler and more useful to others to just put them all here.
See the VMUG VVol webinar here:
You can get my slides here.
Would VVols replace the requirements for RDM’s?
Answer: Maybe. It depends on why you are using RDMs. If it is simply to allow sharing or overwriting between physical and virtual. VVols will replace RDMs. If it is to make it easier to restore from array snapshots, VVols will replace them. If it is for Microsoft Failover Clustering, VVols are not supported with that yet. You still need RDMs. Though VMware is supposed to be adding support for this in the next release. See this post for more info. Continue reading “VVol VMUG Webinar Q&A Follow Up”
I’ve had a few customers ask me what are the minimum vCenter permissions required to register a VVol VASA provider. The use case is, I want my storage admin to be able to do it, but I don’t want them to do anything else.
While this can be done in a very slick way with vRealize Automation (more on that in a later post), this can be done with standard vCenter permissions too. Continue reading “Required vCenter Permissions for Registering a VVol VASA Provider”
One of the most strategic benefits of Virtual Volumes is how it opens up your data mobility. Because there is no more VMDK encapsulation, VVols are just block volumes with whatever file system your guest OS in the VM puts on it. So a VVol is really just a volume hosting NTFS, or XFS or whatever. So if a target can read that file system, it can use that VVol. It does not have to be a VMware VM.
Let me start out with: YES our VVols deployment will be GA VERY soon. I am sorry (but not really) for continuing to tease VVols here.
This is one of the reasons we do not treat VVols on the FlashArray any differently than any other volume–because they aren’t different! So there is no reason you can’t move the data around. So why block it??
Some possibilities this function opens us:
- Take a RDM and make it a VVol
- Take a VVol and present it to an older VMware environment as a RDM
- Take a VVol and present it, or a copy of it, to a physical server.
- On the FlashArray we are also introducing something called CloudSnap, which will let you take snapshots of volumes (aka VVols) and send them to NFS, or S3 to be brought up as a EBS volume for an EC2 instance.
Continue reading “VVol Data Mobility: Data from Virtual to Physical”
I have blogged a decent amount recently about VVols and in many of those posts I mention config VVols. When using vSphere Virtual Volumes, VMs have one, some, or all of the following VVols types:
- Data VVols–every virtual disk you add creates a data VVol on your array
- Swap VVol–when you power on a VVol-based VM, a swap VVol is created. When you power it off, this is deleted.
- Memory VVol–When you create a snapshot and store the memory state or when you suspend a VM, this is created.
- Config VVol–represents a folder on a VVol datastore.
This statement about config VVols deserves a bit more attention I think. What does that really mean? Understanding config VVols is important when it comes to recovery etc. So let’s dig into this.
Continue reading “What is a Config VVol Anyways?”
Quick post. I did some light board videos together on vSphere Virtual Volumes. Lightboard videos are pretty fun to do, the unfortunate part is that I have horrible hand writing. So I immediately apologize for that.
A common question I get with these videos is how do you write backwards. I don’t. I am nowhere near that skilled, as you can see I can barely write forwards. I write normally which appears backwards and the video team mirrors the video.
This is a three part series, the entire playlist can be found here:
Continue reading “VVol Lightboard Videos”
Migrating VMDKs or virtual mode RDMs to VVols is easy: Storage vMotion. No downtime, no pre-creating of volumes. Simple and fast. But physical mode RDMs are a bit different.
As we all begrudgingly admit there are still more than a few Raw Device Mappings out there in VMware environments. Two primary use cases:
- Microsoft Clustering. Virtual disks can only be used for Failover Clustering if all of the VMs are on the same ESXi hosts which feels a bit like defeating the purpose. So most opt for RDMs so they can split the VMs up.
- Physical to virtual. Sharing copies of data between physical and virtual or some other hypervisor is the most common reason I see these days. Mostly around database dev/test scenarios. The concept of a VMDK can keep your data from being easily shared, so RDMs provide a workaround.
Continue reading “Moving from an RDM to a VVol”
Virtual Volumes change quite a lot of things. One of these is how your storage volumes are actually connected. This change is necessitated for two reasons:
- Scale. Traditional ESXi SCSI limits how many SCSI devices can be seen at once. 256 in 6.0 and earlier and 512 in 6.5. This is still not enough when every virtual disk its own volume.
- Performance. Virtual Volumes are provisioned and de-provisioned and moved and accessed constantly. If every time one of these operations occurred a SC SI rescan was required, we would see rescan storms unlike this world has ever witnessed.
So VMware changed how this is done. Continue reading “Virtual Volumes: VVol Bindings Explained”