Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual machine PCI passthrough

Virtual machines including VirtualBox and KVM/QEMU support direct access to PCI devices (using a technology known as "passthrough"). I was able to pass through my NI PCI-6259 to a Windows 7 guest running on a Linux host. NI-MAX (running on the guest) detects the card fine and the self-test passes. However, when I load the test panels and run the analog input test, I don't see any plots on the screen. The card works fine in a Windows 7 computer.

 

The reason why we are trying to set up NI to work in a virtual machine is because we have other pieces of software and hardware that work better under Linux. We are trying to avoid having a multi-computer setup if possible.

 

Has anyone successfully gotten data acquisition working using PCI passthrough? 

0 Kudos
Message 1 of 9
(6,458 Views)

While NI hardware is not officially supported on virtual machines it has been done in the past but I know virtual machines can have issues interfacing with the PCI bus. More information on this can be found in the link below. 

 

Are NI Products Supported on Virtual Machines (VMs)?

http://digital.ni.com/public.nsf/allkb/31B0985265CA167886257831003F5536

 

 

0 Kudos
Message 2 of 9
(6,373 Views)

Thanks. I did see that article, but it seems to be outdated as virtual machines now allow direct access to the PCI bus. I actually tested it and was able to get a M-series card working in a virtual machine. I ran into other compatibility issues (with another device) so gave up and installed Windows 7.

 

It's a shame. I really want to see better Linux support from NI. We are trying to move away from Windows for our experiments as Linux is a much better platform for development.

0 Kudos
Message 3 of 9
(6,371 Views)

The issue isn't really with NI and Linux we have support for PCI on various Linux OS but the issue will be communicating with the virtual machine. Additionally, there is a difference between Windows and Linux for the DAQ driver. While Windows will use NI-DAQmx, Linux will use NI-DAQmx Base. I have included the link for this download as well. 

 

NI-DAQmx Base 15.0 - CentOS, RedHat, Scientific Linux, SUSE

http://www.ni.com/download/ni-daqmx-base-15.0/5644/en/

0 Kudos
Message 4 of 9
(6,368 Views)

Thanks. The real problem is that NI's Linux support is very subpar. NI supports only Redhat-based distributions and ignores Debian-based distributions. While I'd be willing to switch to a Redhat distribution to use NI hardware, the other issue is that only a subset of NI's hardware is supported. In fact, only two PCIe devices appear to be supported. Given that PCI slots are becoming rarer and rarer in modern computers, this means that NI's Linux options do not appear to be a viable, long-term option.

 

Also, NI's 24-bit acquisition cards don't appear to be supported on Linux (I use these extensively). 

0 Kudos
Message 5 of 9
(6,366 Views)
The problem is even worse: they only support *specific* kernel versions / builds. (yes: it must be *binary* compatible). Their silly gpl condome doesn't help either, neither technically, nor legally. Kernel modules are derived work - they always have to use *internal* interfaces, which can change anytime. (the only external and stable interfaces those into userland) As long as NI doesn't understand that fundamental fact, and publishes their kernel drivers and/or the necessary specs, the situation will only get worse, as more and more kernel hackers dont tolerate gpl violations anymore (as eg. done on usb subsystem).
Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 6 of 9
(6,343 Views)

I totally forgot about the kernel compatibility issue as well. I remember trying to get the Linux drivers working on a system, but I couldn't downgrade the kernel due to some newer hardware present in the computer. Sure, I could probably have backported some kernel patches and recompiled an older kernel. At that point, I might as well put the effort into finding another vendor that has better Linux compatibility.

0 Kudos
Message 7 of 9
(6,338 Views)

@bburan-ohsu wrote:

I totally forgot about the kernel compatibility issue as well. I remember trying to get the Linux drivers working on a system, but I couldn't downgrade the kernel due to some newer hardware present in the computer. Sure, I could probably have backported some kernel patches and recompiled an older kernel. At that point, I might as well put the effort into finding another vendor that has better Linux compatibility.


I'm currently writing drivers for the Duagon Ionia machines (*much* cheaper than the cRIOs, certified for railway applications in harsh environments). Kernel itself (v4.12) is up and running, yet a bit stuck w/ IIO drivers. But their old userland driver library should still work w/ the new kernel. In contrast to NI, Duagon does hand out the sources of their proprietary drivers (w/ NDA), if you just ask politely. Once we've finished IIO drivers, that will be obsolete.

 

OTOH, my client has his own boards in the pipeline (singleboard w/ two SoCs) - expecting final HW in about 2 weeks on my table, so up and running in September.

 

If you're interested, I could arrange contact.

@(just call me @+49-151-27565287) 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 8 of 9
(6,083 Views)

Ah, maybe another option:

 

If you already did the mistake of buying an NI card, but that one is indeed running on a old system w/ their proprietary drivers, you could put that in a VM w/ PCI passthrough.

 

And if the're enough people w/ the same problem, it might be worth just reverse-engineer the whole stuff and publish the results in the wide net. This already had been done w/ really hostile companies like NVidia (and BTW showed some up their frauds).


Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 9 of 9
(6,080 Views)