OmniOS r151058 has been released - omnios.org/article/r58 - the old LTS r151046 is now end-of-life

Anyone seen this on an OmniOS host before? "May 4 00:04:45 fs1 ixgbe: [ID 611667 kern.info] NOTICE: ixgbe1: ixgbe_rx_copy: allocate buffer failed"

One of our file servers went south this morning. It recovered fairly quickly, but not before all the VMs that got their VDIs from it died.

new release, yess!

naive question: where does this wording "<change-No> want xxx" in the PR description?

congrats on the new release!

just updated, all systems up and running again

as always, thank you @ omnios team :)

Updating HDC to '058 tonight!

my bhyve VMs are no longer booting after upgrade, I assume because of the virtio changes?

any config toggles one may have found to remedy the situation?

What are the VMs?

There are some Linux guests which break the virtio spec. You can disable the new modern virtio interface by setting 'virtio.modern=false' in the VM parameters.

thanks andyf, I just came back to comment that solution

my guests are OpenBSD

Oh, interesting. The linux bug is bugs.launchpad.net/ubuntu/+source/linux/+bug/2045443 but I wonder if openbsd has something similar, or if it's us.

I just did zonecfg -z $zone 'add attr; set name=extra; set type=string; set value="-o virtio.modern=false"; end'

I found the following in init.log: Assertion failed: mr->name == memp->name, file ../common/mem.c, line 362, function unregister_mem

I'll have to try and boot up openbsd myself.

looks similar to smartos.org/bugview/OS-6836 ?

→ OS-6836: bhyve Assertion failed: mr->name == memp->name, file mem.c, line 265 (Open)

It certainly does. 2018!

I get the same on a VM I just set up. Interesting, especially if it's triggered by the modern virtio mode

looks like it! I just tried "virtio.legacy=false" as well (in case the transitional glue was the culprit), but it produces the same mr->name == memp->name assert

I will look into it. Mine is doing it even with virtio.modern=false, it's happening in the nvme device for me.