2011-01-25 11:40 PM - last edited on 2014-09-25 03:46 PM by alissa
i am a Unix/Linux Specialist and i run Linux on my notebook and our prefered virtualisation is KVM.
I am able to boot the simulator under KVM, the only thing that is not working are the NICs; my KVM is passing 4 e1000 NICs to the simulator but he does not recognize them althoug VMWare is passing the same hardware.
I know this is not supported, but it would make my life much more easier; i have to run my Windows that i need to administrate the simulator in a KVM VM and KVM and VMWare cannot run both at the same time on one system.
2011-01-31 07:50 AM
The short answer is that the DOT8 simulator expects specific identification and behavior from the underlying virtual devices. If you can get KVM and Xen to provide virtual devices that look and act exactly like in VMware, then there's a good chance that it will work. I know that a bunch of people have tried with Hyper-V without much success. If you get simulator to boot and get configured in KVM, then that's already good progress. Does KVM provide options for fine-tuning the virtual NIC type? If so, perhaps by playing with those options you'll hit on a combination that works. The simulator engineering team has their hands full and isn't going to be doing any development and testing related to KVM and Xen any time soon, so it's entirely up to the KVM/Xen experts on this community to figure out what's possible.
Take care and hope that helps,
2012-07-25 07:04 AM
2012-08-14 05:54 AM
I believe that the PCI IDs for the virtual E1000 intel NICs are different. ESX emulates a device with PCI ID 8086:100f, KVM uses something different (I'm not at home ATM, I can't look it up right now). I suppose that the ONTAP NIC driver binds only to those PCI IDs used by ESX, not those used by KVM (or XEN, they both use QEMU for device emulation).
AFAIK there is no way to tell QEMU which PCI IDs to emulate. You would probably have to patch the source code.
2013-06-03 06:27 AM
I've been digging into this somewhat after I read this and I'm not quite sure but the following from http://wiki.qemu.org/Documentation/Networking:
Note that there are other device options to select alternative devices, or to change some aspect of the device. For example, you want something like: -device DEVNAME,netdev=NET-ID,macaddr=MACADDR,DEV-OPTS, where DEVNAME is the device (e.g. i82559c for an Intel i82559C Ethernet device), NET_ID is the network identifier to attach the device to (see discussion of -netdev below), MACADDR is the MAC address for the device, and DEV-OPTS are any additional device options that you may wish to pass (e.g. bus=PCI-BUS,addr=DEVFN to control the PCI device address), if supported by the device.
Seems to indicate that it is possible to 'control the PCI device address'.
2013-06-03 02:29 PM
Unfortunately, I wasn't talking about PCI addresses, but about PCI IDs. A PCI ID is an unique identifier to a specific brand of PCI card (for example, an Intel E1000 NIC). You can see them in the output of "lspci -n", or a list of a whole lot of them in /usr/share/misc/pci.ids or at http://pci-ids.ucw.cz). Sometimes, different revisions of the same brand get a new PCI ID, which happened to the Intel E1k. So VMware emulates E1k NICs using one PCI ID, and KVM uses another. The only way to change that is to change the source code (see the files hw/net/e1000.c. include/hw/pci/pci_ids.h and include/hw/pci/pci.h in Qemu's git repository at http://git.qemu.org).
That would (probably, never tested) make Ontap's e1k driver recognize the device. If the emulated device then still talks the way the driver expects (because it is actually meant to talk like a different device) is a different story altogether. It _might_ work, if the two kinds of e1k NICs are similar enough, but you just as well might get weird errors, lockups, random packet losses, whatever.
2013-09-01 05:21 PM
FWIW, VirtualBox uses the same 82545EM / 8086:100f device that VMware uses and it at least booted up to the password prompt when I tried it.
qemu-kvm would be way way way better though, I'll try your idea of hacking the ID in the source and see what happens.