Freenas Virtio Drivers

Solved Installing FreeBSD With VirtIO. I use VirtIO for networking and for storage and usually install without. You install FreeBSD without VirtIO drivers.

The virtio_random(4) driver, allowing a VM guest to use the host as an entropy source, is not built in to the kernel nor provided as a module in 9.10.2: [rob@freenas /]$ kldstat -v grep virtio 414 virtio_pci/virtio_scsi 413 virtio_pci/virtio_balloon 412 virtio_pci/virtio_blk 411 virtio_pci/vtnet 410 pci/virtio_pci 409 virtio The device is recognized at boot time, but no driver is attached: virtio_pci2: port 0xc100-0xc11f irq 11 at device 4.0 on pci0 Presumably this is a simple kernel config update to add -- please do! Alexander Motin wrote: I've decided to close this.

I don't like existing driver enough to just add it to the kernel, while we have not enough time and motivation to rewrite it. I'll let somebody in FreeBSD do that first. This is a year old request to enable a driver shipped by upstream that solves a real world problem today. If there are material issues with the driver that anyone intends to fix within FreeBSD itself, is there any reason why that wouldn't be done in place? This is also the simplest of the virtio drivers, and hasn't had any significant changes in the nearly five years it's been present in FreeBSD, so it sure doesn't look like anyone's in any particular hurry to fix whatever you believe to be wrong with it.

What, exactly, is your concern with enabling a driver that should be irrelevant in any situation in which the target device is not present? Stick war 2. There are several sides of my opinion: - The driver in its current design supplies only 16 bits of entropy in 5 seconds, and first time it does that 5 seconds after attach, by which time system already obtains some entropy from other sources.

Sure, any amount of good entropy is good, but I am not sure it exactly solving world problems now. - The driver in its current design works synchronously, so if at the point host itself is low on entropy, guest CPU may block indefinitely. I don't like it. - It could be integrated tighter into the random subsystem as real hardware entropy source to provide as much entropy as needed and when needed, but that require closer look on the subsystem and complete driver rewrite.

I am not saying it would not be good to have it, but I simply don't fee like it is high enough among our priorities as a NAS developers. Unfortunately we have to choose on which fronts to advance.