There are some tidbits about this in various forums, none of which declare any official impact to VM performance. However, there was a VMware KB published that recommended this be disabled. that said, the KB no longer exists. Go ahead and access it and see the page can't be found message: https://kb.vmware.com/s/article/2145889
So I'm officially reaching out to the experts at VMware to ask, is there any impact to this setting being enabled? My guess is no, which could be why VMware took down the KB. But it would be better suited to leave a KB up and simply state that its safe to ignore this, or otherwise provide some guidance for customers.
Thanks in advance to your advice
Generally you want a device to either be configured with virtualization (like vmxnet3 for networking) or in passthrough mode (with DirectPath IO enabled). Having DirectPathIO enabled with VMXNET3 is just a misconfiguration. It was a bug and it has been fixed.
Depending on the application networking performance needs vs. virtualization benefits (like vMotion, HA etc.) you would want to configure your networking device appropriately. There is usually some overhead to virtualization , but the benefits obtained need to be weighed against the performance consideration.
Vmotion continues to work unless there is actually a true mapping to the PCI device where direct path IO is in proper use.
the question that needs answering is whether enabling Direct Path IO on the vmxnet3 adapter will have any performance impact on the VM when there is no actual mapping to a PCI device. After all, enabling Direct Path on VMXNET3 is useless without a mapping to the PCI device, so for the most part, at first glance, its just a check box checked that isn't really doing anything. But VMware should have an answer as to whether there is a performance impact to the VM when this check box is checked and no actual mapping to a PCI device exists.
IMHO is an interesting question,
In vCenter 7.0U3C when creating a new virtual machine and adding a VMXNET3 network adapter, as stated by @kwg66, it did select by default the DirectPath I/O option. I beg your pardone, but if it's a bug in the vCenter GUI interface, then is not resolved.
Beside doing apparently nothing I also dig on the web about this option but also I have not found any clear indication on Vm impact performance.
Well, a "lab" obviously is not a production environment but I tend to approxymate it as much as possible, eventually replicanting useful thing on the "real world".
Thanks for chiming in Kinnison - I think we can all agree that our employers don't care to have us spending time in a lab environment trying to understand the behavior of VMware issues that they themselves should have a handle on and properly advise customers about. 🙂
Even with the vCenter 7.0U3g object whenever a virtual machine with a VMxnet3 network interface is created, still the "direct path I/O" option get enabled by default. A bug supposed to have been corrected some time ago, but no, it is still there (and it is not the only, long standing, one).
I see from the case description that you are requesting information in relation to DPIO being enabled on your VMs.
The presence of the checked "DirectPath I/O" field in the VMXNET3 network adapter is a sub optimal UI name for an old, rarely used feature (ethernetX.uptCompatibility, "Universal PassThrough", basically allowing vMotion for Passthrough NICs on Cisco HW with a specific 3rd party VDS) that currently doesn't do anything. There is no impact on having it enabled.
"The support for DirectPath I/O enabled has been removed. i.e uptCompatibilityEnabled property is no longer supported." This is from one of our internal documents.
DirectPath I/O would not be in use until it is configured to do so on the host. This can be configured by enabling a passthrough device for a network adapter on the host.
Once this is enabled, the VM a can then be configured to use this passthrough device by adding a PCI device as an adapter and in turn using DirectPath I/O.
So it's seems another incongruity of the user interface of the vCenter object that no one has bothered to remedy while acknowledging its obvious uselessness.