• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

ESXi Passthrough not activating

Can't speculate about engineering internals, but I work in an OS dev environment, and we have undocumented, unsupported interfaces, some of which are, well, not robust... I can say that when I tried local RDM a couple of years ago, I got a corrupted zfs pool. I'm not the only one either - I'd listen to lopo were i you :)
 
lopoetve, Why is doing RDM Passthrough not a good idea?

Also I just emailed super micro tech support, like EZStuff said if they get enough people complaining maybe they'll do something.

Copying from a prior post:

So, HBA is a misnomer - in effect, all "local" controllers are HBAs the same as any other - they connect the PCI bus to a SCSI bus.

Except local controllers aren't SCSI for what most people are doing. So, we're expecting something that fully supports all SCSI commands, and doesn't really support them. In addition, RDMs have a pair of commands that are modified to them at all times: REPORT_LUNS, which doesn't matter, and BUS_RESET, which we convert to a LUN_RESET (because resetting a bus is good for local devices, which the VM thinks it has, but a really bad idea for SAN devices). Thus, we're trying to change commands to something that a remote device would normally be perfectly happy with, but a local controller may go "WTF" to. On top of that, we're expecting a certain set of responses to INQUIRY that a local device won't return (Because it doesn't support them), which means we're making assumptions about device capabilities that may not exist End result - we send commands, local controller goes "... ?!? ... purple? ... YAHTZEE!" and your VM gets unhappy.

In effect, we're expecting to be talking to a certain device (a remote RAID controller on an array), and instead talking to something totally different (a single, local SATA disk most of the time), and the commands aren't 100% compatible.

It works "better" on certain local true SCSI controllers, as they can interpret the commands, but they're still not 100% identical to what a SAN or remote device would present, so there are still potential issues there.

That help?

Support can't really push new features - file feature requests instead (yes, we really do look at them, I'm serious). Support side - they don't listen as much ;)

That being said though, local RDM won't work that cleanly - we have some ideas there, but there are inherent difficulties with it. Passthrough is the same way - there's an almost infinite set of devices to test against. :)
 
from supermicro support, it's basically not possible:

I duplicated your issue on my system here. I also talked to my engineers and they said that SCU device cannot be passthroughed because it is already under two switches.
From your screenshot you can see that the SCU device is under the virtual switch port, which is under another upstream port that is under the root port. This is the hardware limitation of SCU.
 
Update!

Not support right now, but support is coming down the pipe, here is the latest from Supermicro Support.

"According to VMWare, they currently have a beta driver but not available to the public. They will not have a production driver until early next year, sometime in January."
 
I like how we both got conflicting information! Hopefully yours is correct, but i just ordered a pcie array controller last night.
 
Back
Top