3

So, we have a production system with two Windows Server 2012 R2 Standard Servers with a shared storage SAS dual domain backplane between them.

If you're unfamiliar with that, it basically lets both machines have direct access to the same physical storage.

However, we have data software that runs on one of our VMs and thrashes our HDDs pretty relentlessly. It works, but at basically 100% disk IO. The thing is, it doesn't need to. All the data it thrashes the HDD with is temporary data, and could be regenerated from the source easily.

We have some non-shared SSDs in our production servers that if we could make some kind of volatile VHD that lost it's data when migrating, but would otherwise allow reading and writing from the SSDs instead of the main HDDs we could drastically speed up our data software.

Does anyone know how to make a volatile vhd like this?

1
  • 1
    Are you using Storage Spaces? Create tiered storage with SSDs and HDDs, thus you will get performance out of your HDDs.
    – Strepsils
    Jun 22, 2017 at 7:01

2 Answers 2

1

I'm assuming from your description that you are running a Failover Cluster on these two machines, that you've set up clustered Storage Spaces, and that the VMs themselves are marked as cluster resources (highly-available) so that they'll fail over from one node to the other if a host goes down.

Assuming all that, the best way to make local SSDs available to the guest VMs would be to make a file share from them and use that file share from within the guest. I.e. don't use a VHD to solve this problem.

Any other solution would have the property that the VHD just disappears when the host dies. The VM will then fail in one of several ways. Even planned VM migration wouldn't work, if some of the VHDs of a clustered VM are stored locally.

If the underlying host dies, at least by using a remote file system, you'll have the OS primitives in place that can gracefully handle the disappearance of a file server.

3
  • 1
    This does work, but the network interface emulation slows it down immensely, and leaves me with a different bottleneck. I'd actually be ok with something where the VHD disappears when the host dies. If I could somehow have an A drive and a B drive, where only one is there at any given time, that'd work too. (e.g. On Host A, VHD A would be accessable to the VM, and on Host B, VHD B would be accessable to the VM. Jun 22, 2017 at 21:59
  • If you find it acceptable that the VM dies when the host dies, then don't cluster the VM and you can do what you want. There is no middle-ground where the VM gets moved to another cluster node and the VHD disappears. This is a feature of VMs in Azure, but not Hyper-V outside of Azure. Jun 22, 2017 at 22:48
  • 1
    Dang. Well at least it being a feature in Azure means that it might one day come to Hyper-V. Thanks for your help! Jun 22, 2017 at 23:59
5

I would recommend trying RAM drive if you have enough free memory. For temporary data, this is the best option in my opinion. When it comes to a RAM drives the main drawback is the redundancy, however, you mentioned that it is possible to lose a VM thereby the main drawback become eliminated.

For Windows https://www.starwindsoftware.com/high-performance-ram-disk-emulator

For Linux https://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-linux

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .