Home / server / Questions / 856936
Accepted
Andrew Hendrix
Asked: 2017-06-21 14:27:21 +0800 CST

Hyper-V 2012 R2 Shared Storage non shared temporary drive

  • 772

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?

windows-server-2012-r2

2 Answers

  1. 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

    • 5
  2. Best Answer

    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.

    • 1