Poor Virtual Machine Virtual Disk Performance

[MitchellStringer]

I have recently started using some VMs for various tasks. I have Drivepool installed on the host (Windows 10) and virtual disk files (VDI / VDX) saved in the pool (32TB across 10 Disks)

 

Each Virtual Disk is about 60GB

 

The issue is when I run a VM (Windows 10 client) the client Task manager reports 100% disk usage and the VM is VERY sluggish, (2-3 minutes to open task manager)

 

As a test, I moved the VM Virtual Disk to a Physical Hard Disk not in the pool and the VM performance was a lot better, no more 100% disk usage (night and day difference)(WD 4TB Red)

 

As another test I moved the VM Virtual Disk to a Physical Hard Disk which is part of the pool and had the same issues with performance (WD 8TB Red)

 

Drivepool is doing something that is causing access to the Virtual Disk file to be really slow.

 

In the Host, When the virtual disk file is in the pool, the pool disk that the virtual disk file is saved on, also sits at 100% when the VM is running.

[Jaga]

I don't work with virtual machines much, but I do a lot of performance metrics.  If there are special considerations with how the host accesses the VM files I'm not privy to them, so take my suggestions with a grain of salt.   

If the VM disk in this test was not inside the hidden Poolpart-xxxxx folder on that drive, then Drivepool shouldn't have been interacting with the host's access to it.  Knowing exactly where it was and how you accessed it to spin up the VM for the test would help.

To get an idea of what could be causing it, these are the tests I'd run and compare:

1. Place the VM's file in the root of the volume (a volume in the pool, but not inside it's hidden Poolpart-xxxxx folder), run a test against it there.
2. Move the VM's file into the volume's hidden Poolpart-xxxxx folder, but run the test against the local drive's letter/path (not the Pool's).  i.e. if your Pool has letter D:, and the individual drive/volume has letter G, use "G:\Poolpart-xxxxx\filename.xxx"
3. Stop the Drivepool service, then spin up the VM using the pathing from test #2 again.
4. Start the Drivepool service.  With the VM's file still inside the Poolpart-xxxxx folder, re-measure the pool.  When done, run the test against the VM's file via the Pool letter/path.

In tests 1 & 2 the file for the VM isn't referenced via Drivepool at all, so you're looking at Host OS access only.  In test 3 we go a step further and completely disable Drivepool - if the result is different from test 1 or 2, make a note of it.  In test 4 we do a regular pool access test.  If the slowdowns happen even in test #3, then there may be an issue with the physical drive/controller.

Theoretically all four tests should be nearly identical, from a performance perspective.  That is - unless VMs have special considerations for file access.  I did read a post/blog(?) from several years ago where Christopher stated the developer Alex stores his VM files in the pool, so there's a good chance it should work fine.

[JasonC]

Just a wild guess off the top of my head as a possible thing...check on the host where your physical disk activity is happening. You mentioned your using virtual disks, are your virtual disk files consuming the majority of the space on the physical disks, or do you have it sliced up so you are presenting multiple disks to DrivePool from a single disk?

Using virtual disks means that you're hiding the real physical layout from DrivePool. DrivePool thinks of each disk as a spindle though. It won't know any better. So if you have 3 virtual disks that reside on a single physical disk, DrivePool may be sending more disk operations to the physical disk then it realizes, because it thinks it has 3 different disks. So 3x the operations but still 1 physical disk servicing requests.  So effectively you'd be choking yourself out by throwing way more iops at the physical disk. DrivePool could be throwing parallel operations at a single spindle. Check the perfmon counters for the physical disks hosting your drive pool, I'd look at queue depths in particular, and probably read and write operations.

I run a VM as well to host my pool, but I am doing passthrough of the pooldisks, so DrivePool does have a real 1-to-1 mapping of spindles and pool disks.