How Virtual Disks are bringing sexy back

By Eric Carter | | Software-defined Storage

OK – let me admit that I used an online blog idea generator to come up with this title. I passed on other suggestions like “Virtual Disks are cooler than Taylor Swift” and “Virtual Disks killed Kenny” but the “Sexy Back” seemed to set the right tone for what I want to say. Why? With the advent of software-based distributed systems approaches to storage, the industry has entered a renaissance period. One of the sexier parts of the approach is the concept of Virtual Disks as the logical unit of provisioning.

Not unlike a storage LUN on a SAN, the Virtual Disk is a “carving out” of capacity that can be provided to one or more compute resources for use. In the case of software-defined storage the volume is created out of a pool of capacity presented by a cluster of server nodes with disks (HDD and SSD) in either a hyperconverged or hyperscale deployment – or both. What makes it virtual? Well, with Hedvig, until a Virtual Disk is written to, it exists only in metadata. This makes provisioning extremely fast – you can spin up any number of volumes instantly. When written to, each Virtual Disk is thinly provisioned atop the commodity infrastructure, and the data is distributed across the nodes of your cluster.

The Virtual Disk – sometimes referred to as a vDisk – is the fundamental abstraction unit of the Hedvig Distributed Storage Platform. When we demo the solution we will typically use our graphical user interface (GUI) click a few buttons and BLAM a large number of volumes are ready to go. What makes this even more powerful is that you can essentially have this process happen automatically – programmatically via APIs – directly via your application(s). We do this with Docker for instance. When you spin up a container, a Hedvig Virtual Disk can be created for it on-demand. If simple is sexy, Virtual Disk provisioning is hot.


One of the really sexy things about Virtual Disks is that you can quickly and easily give each its own personality. (Like long walks on the beach? Have we got a volume for you!) What I mean is that you can define a series of attributes or features per Virtual Disk to make it a perfect fit with any given application. With Hedvig the list of assignable features include:

  • Name
  • Description
  • Size (capacity)
  • Block size (512bytes to 64k)
  • Disk type (block, file, object)
  • Residence (HDD, SSD)
  • Client-side caching
  • Compression
  • Deduplication
  • Replication factor (# of copies)
  • Replication policy (where to put copies)

Why is this sexy? Well, for starters, we know that inside the enterprise you have a large number of apps and data types to deal with – no two created exactly equal. Having the control to tailor storage to the app is a great advantage (especially when it’s so easy to do). For instance, let’s say we need storage for three workloads – a SQL database, a backup-to-disk target, and a marketing image and video archive repository. We can define our storage to fit the needs of each:
Virtual Disk for SQL database

  • 20GB volume
  • Block storage accessed via iSCSI
  • 64k block size
  • SSD residence (pin to flash)
  • Client-side caching to accelerate reads
  • 3-copy replication factor
  • Datacenter-aware replication policy

Virtual Disk for backup-to-disk

  • 750GB volume
  • File storage accessed via NFS
  • 4k block size
  • Deduplication/compression
  • 2-copy replication factor
  • Datacenter-aware replication policy

Virtual Disk for images/video

  • 2TB volume
  • Object storage bucket accessed via S3
  • 64k block size
  • Residence: HDD
  • 2-copy replication factor
  • Rack-aware replication policy

This kind of flexibility makes life easier on application developers and IT administrators alike – and is a great way also to configure storage for multi-tenancy as each tenant can have unique Virtual Disks with tenant-specific storage policies (I’ll save the multi-tenant topic for a future blog). For more on provisioning, download our tech overview whitepaper.


Life for an application usually begins inside of a test/dev environment. This often means that you don’t need exactly the same storage profile during development that you will once you push your app to production. In test/dev you may be satisfied with storage to hard disk and a single copy of data. In production you may want an all-flash experience, full caching, and data protected across racks and/or data centers.

With Hedvig, the good news is that you can do all of your development with Virtual Disks of one personality, and then when its time to move to production, simply create clones of your Virtual Disks and as a part of the cloning instructions change key parameters before you push your app into production. The result is a new Virtual Disk with the personality you need for your application to be successful in production.


This week we are implementing a new program at Hedvig. Once a week every Friday like clockwork, we will host a live online Hedvig intro and demo where we will describe our solution, highlight the difference it makes for customers, and then show you the software in action – including everything described above. YOU’RE INVITED! If you’re new to Hedvig, jump on – if not this Friday, then next Friday, or the next. Just click below to join us.