hashcat
advanced password recovery

Hi! I haven't seen much about using VM:s for GPU workloads, and I haven't seen anything on this forum. So, I though I would write a bit about it here, because I think it's great.

Summary
It works. No performance penalty found, yet.
TL;DR version at the bottom.

About me
I work pretty much every day with designing/installing/maintaining small to almost-enterprise size VMware virtualization systems, using almost exclusively HPE hardware. It's not ALL I do, but it's a major part of my work.
My posts here are my own and are not endorsed, or even known, by my employer, HPE or VMware.

Why virtualize?
(Warning, some VMware marketspeek included)
Virtualization, generally, provides the following benefits:

• Flexibility
  

Virtual guest can be moved around to different hardware and physical locations without downtime
Resources can be assigned from a pool, rather than beeing a fixed size decided at instalation time

• Agility
  

Resources can be quickly changed; CPU/memory can be hot added
Network redesign can be done without affecting the guests
VM:s can be deployed "instantly", without having to order new hardware

• Availability
  

In case of a host (hardware) failure, guest can be automatically restarted on other hosts
Much reduced hardware in the guests reduces the amount of drivers that can cause problems

In this case, using ESX to host guest running oclHashcat, the following benefits are also realized:

• Hardware utilization
  

Using a physical box just to power GPU:s is a waste of space, power and CPU resources. Why not use the box for other purposes at the same time? (Like running a hashtopus installation)

• Maintenance made easy
  

It is a known issue of all (?) OS:es that AMD and nVidia drivers cause each other problems. Using virtualization, you can install separate guests for AMD and nVidia GPU:s, with the right drivers in each without conflicts. Or why not have one guest per GPU?
OS, driver and hashcat updates may cause problems or performance issues. Resolution: power down guest, snapshot, power up and perform update(s), test. If issues occur, revert snapshot. In case of a multi-GPU box, do this for one VM with one GPU. When the update procedure is finalized, repeat it on the other guests; downtime is greatly reduced.

• Different versions
  

Different versions of hashcat may perform better or not at all with some GPU:s. Install as many guests as you need, with different versions that fits your need. Move the GPU around to the guest that best fits the situation. Run different versions for different GPU:s, all in the same box.

Why NOT virtualize?
The oldschool way of thinking is that "if you need performance, you need dedicated hardware". This is not true anymore; first, hypervisors have matured and does not cause much overhead. Second, most overhead from virtualization is on the CPU part. CPU:s today are hardly ever bottlenecks - and if they are, you can add more cores. The only instance you may actually require dedicated hardware is if your application needs very very high single-thread performance. Well that and if your idiot vendor says virtualization is unsupported...

A real reason not to virtualize is increased complexity. Yes, virtualization makes the system more complex, it adds another layer of "stuff" that you need to plan, maintain and troubleshoot. If you are unwilling to learn something new, buy hardware.

Design
The goal here is to install a vShere host with one or more GPU:s. These GPU:s are then assigned to VM:s using PCI passthrough. The operating system is ESXi; it is available for free from vmware.com. You need to register and checkout a license, or it will not power on guests after 60 days. The free license is limited to 8 vCPU/guest and cannot be connected to VMware vCenter (=> no cluster).
ESXi only supports/contains drivers for a subset of hardware. It can be installed on consumer hardware if the hardware is built from supported chips; unsupported hardware may also work with community drivers. Pretty much all ready-made servers today supports ESXi; but a lot of servers to not support high-power GPU:s, or they have insufficient room for large GPU coolers, or they do not have (enough) PCI-e power.
There are a lot of options for hardware, you need to research a bit to find something that works. I use an HPE Ml350p Gen8: it can fit two 2-slot GPU:s/CPU but you need a special power cable for PCI-e power. Fortunatelly, the power socket was compatible with Corsair modular PSU power cables.


Preparation
Download ESXi. If you have a HPE/Dell server, download the custom ISO or you may not have the drivers you need. You can add drivers to the installtion CD but you cannot add drivers on the fly during the installation.
Fit the GPU and make sure it has enough power.
When you (later) add the GPU to your VM, it will reserve 100% RAM that you configured to your VM. If you need 4 gig RAM/VM and 8 VM:s, you need at least 4gig x 8 + (overhead + ESXi) RAM ~= 34gig ram. You are not constrained to whole GB:s here, you may assign 3750MB RAM instead, if you want to.
(Optional:
I recommend setting the VM advanced option "mem.ShareForceSalting" to 0, this enables me to overallocate RAM better (it enables RAM dedup between guests). It won't make a difference on guest with passthrough, though.
Since these VM:s will be in an isolated environment (I hope), I would turn off ASLR to increase guest RAM dedup.
Overallocating CPU is OK, but will notice increased latency for certain applications. Web server generally do not perform well on overallocated CPU - you may apply this fix to the VM if you think you need it: http://kb.vmware.com/kb/1018276. But consider the fact that you will be burning away some CPU that may be used for other VM:s instead. Also, those idle loops are counted towards the guest resources shares - you may end up with using half your CPU for nothing and not be eligible for CPU when you need it. SQL servers are not bothered by CPU latency; performance decreases with less CPU available, but it will use those CPU cycles effectively.
If you REALLY want to reserve an entire core (or several) for your guest, change CPU reserve to 100% and set the advanced option "monitor_control.halt_desched" to false. Your VM will now never be required to share it's core. Also, if you have hyperthreading active (you should), you may ensure that the other thread is not used by setting Hyperthreaded core sharing: none. This ensures that your VM will have 100% of the core cache and CPU time.
)

Installation
Install ESXi.
Connect to ESXi using a web browser and download vSphere Client (the client is version specific and the link is to and Internet URL).
Configure time and date. This is important: when a guest is restarted or a snapshot reverted, the guest time is set to whatever ESXi has. Is is a reoccuring problem that this step is forgotten, and VM:s start up with the wrong time/date.
In vSphere client, select your host, tab Configuration, option Advanced Settings. Enable PCI passthrough on your GPU. Reboot.
Install a VM to run oclHashcat. I use Ubuntu according to this guide: https://hashcat.net/wiki/doku.php?id=linux_server_howto Thus, I have a 64bit-only installation, version 14.04, with 'fglrx' drivers.
Install open-vm-tools; trust me, you want it. You will then be able to right-click "shutdown" instead of "poweroff" and you will see the IP addresses in vSphere client.
When the VM is installed and updated and works like you want it to, shut it down and edit the virtual hardware.
Add the PCI device (your GPU).
Start your MV, get oclHashcat.
Done!

Benchmarking
This is from my server, running ESXi 5.5 on an HPE ML350p Gen8, and a second-hand Radeon 6970. The host is running a total of 12 VM:s with total 17 vCPU:s, on a single 4-core Intel E5-2609 (no hyperthreading). 48gig RAM with 60gig RAM assigned to guests.

CPU usage during benchmark was average ~250MHz, or 10% of core speed. That's a lot of CPU that can be used for other things... ;) It's hash dependant though, some hashes actually used 97% CPU.
Performance of the 6970 I find around the Internets, is MD5=5878MH/s and WPA2≃82kH/s.
I was expecting to get at least 90% of that speed - but the benchmark got _more_ than others have posted for WPA2, and the same (almost) for MD5. It seems performance of hashcat is totally unaffected by beeing virtualized.
My performance is MD5=5698MH/s and WPA2=95kH/s.


Extras
I use hashtopus to control this VM. To start the agent, I use this little script:
The agent execution command line (set in hashtopus agent config) must contain "--gpu-temp-disable" for the fan speed config to work.
Here's a quick reference to the screen command: http://aperiodic.net/screen/quick_reference

You may check GPU temp and fan speed this way:
aticonfig --odgt --pplib-cmd "get fanspeed 0"

Conclusion
Running oclHashcat in a VM instead of on hardware, can be a viable way to optimize hardware usage and ease management, IF you have the knowledge and time to set it up. So far, it seems there is not inpact on performance, though further testing on multiple and more recent GPU:s are needed to establish this as a fact.


TL;DR:
1. Install ESXi
2. Activate PCI Passthrough, reboot
3. Install a virtual guest as usual - add open-vm-tools
4. Shutdown VM and add GPU to VM
5. Start VM, install oclHashcat
6. ?
7. Profit!

Try it, you'll like it! :)

On Reddit and other tech forums there have actually been an explosion of people asking about virtualization and GPU passthrough mostly due to these Youtube videos -

https://www.youtube.com/watch?v=LuJYMCbIbPk
https://www.youtube.com/watch?v=LXOaCkbt4lI
https://www.youtube.com/watch?v=opX-AsJ5Uy8
https://www.youtube.com/watch?v=uKJw8IKVYQ8

Now one question remains: why sacrifice 10% performance for the offered flexibility with 100% uptime guarantee? You can have an uptime of 99.9% without the effort of virtualizing. (unless you need 1h maintenance per day to update the hardware…)

Agility for hot-add/remove ram/cpu? You never need to change that for a GPU cluster.

Availability: yeah. Why the hell do I need 100% availability for a hash cracking cluster? What is the gain? If it's 1% better uptime (doubtful) that still does not account for the 10% of performance loss.

I agree, 10% less performance on a cluster dedicated to gpu-hashing wouldn't make sense. I think you misinterpreted part of my post. The point was to make public my results on running oclhashcat in a VM. My finding was that using the GPU in passthrough mode probably does not affect performance and that it is therefore a viable way to optimize hardware usage and ease management. I mentioned availability as a benefit in the explanation as to why, generally, IT infrastructure is being virtualized.

First, my result was 2,5% less md5 speed, compared to an unsubstantiated claim from someone using different hardware and probably different oclhashcat version
Second, my result was also 15% faster than the wpa2 crackstation benchmark; as you can see, I lack proper data to compare too, however... since the result was either faster or very slightly less, I concluded that no, or very slight, performance impact is introduced.

To make my stance on this clearer then:

1. If you have several nodes doing nothing but hashing, all (but perhaps one) might as well remain dedicated because you're using so much money on hardware that you can afford to solve your other computing needs better.
   
2. When you are evaluating new drivers/versions/OS, you should perhaps consider using a VM because the shortcuts available will not only save you time, it will make your work less tedious. And you could test it on one GPU, while the other 10 keeps working.
   
3. If you have a small number of nodes and would like to not have a separate set of compute nodes, installing a hypervisor could be a good idea if performance doesn't suffer; as I wrote, more testing is needed.
   
4. If you're like me and have: one good lab server, limited budget, space and time and just want to be able to do some hashing while using the box for other things too: this is definitely the way to go even if performance suffers a bit.
   

I hope that makes it clear. But do try to find other deficiencies in my reasoning, I like arguing

(06-21-2016, 02:59 AM)RulerOfHeck Wrote: I agree, 10% less performance on a cluster dedicated to gpu-hashing wouldn't make sense. I think you misinterpreted part of my post. The point was to make public my results on running oclhashcat in a VM. My finding was that using the GPU in passthrough mode probably does not affect performance and that it is therefore a viable way to optimize hardware usage and ease management. I mentioned availability as a benefit in the explanation as to why, generally, IT infrastructure is being virtualized.

First, my result was 2,5% less md5 speed, compared to an unsubstantiated claim from someone using different hardware and probably different oclhashcat version
Second, my result was also 15% faster than the wpa2 crackstation benchmark; as you can see, I lack proper data to compare too, however... since the result was either faster or very slightly less, I concluded that no, or very slight, performance impact is introduced.

To make my stance on this clearer then:

1. If you have several nodes doing nothing but hashing, all (but perhaps one) might as well remain dedicated because you're using so much money on hardware that you can afford to solve your other computing needs better.
   
2. When you are evaluating new drivers/versions/OS, you should perhaps consider using a VM because the shortcuts available will not only save you time, it will make your work less tedious. And you could test it on one GPU, while the other 10 keeps working.
   
3. If you have a small number of nodes and would like to not have a separate set of compute nodes, installing a hypervisor could be a good idea if performance doesn't suffer; as I wrote, more testing is needed.
   
4. If you're like me and have: one good lab server, limited budget, space and time and just want to be able to do some hashing while using the box for other things too: this is definitely the way to go even if performance suffers a bit.
   

I hope that makes it clear. But do try to find other deficiencies in my reasoning, I like arguing

can u perhaps video record all ur work, from a to z so ppl could see and replicate ur work?