I did say "if you can connect via serial console ..", which IIRC for many linux distros means a post install fix before dumping the VNC device ... eg: something like https://www.hiroom2.com/2017/06/19/debian-9-grub2-and-linux-with-serial-console/
@KrisBee Thanks. I was able yesterday to get the VM booting on serial console and it now just has a disk and NIC as the devices. However, I had to again poke the VM via serial (cu -l /dev/nmdmXXX) to get it to wake up before it would serve. Once poked via serial, it instantly came alive. This VM is running Ubuntu 18.04.3. It seems to have the same issue as before.I did say "if you can connect via serial console ..", which IIRC for many linux distros means a post install fix before dumping the VNC device ... eg: something like https://www.hiroom2.com/2017/06/19/debian-9-grub2-and-linux-with-serial-console/
create_zvol: false sectorsize: 0 type: VIRTIO path: /dev/zvol/tank/rancheros-wgkzbe
nic_attach: igb0 mac: 00:a0:98:17:c3:60 type: E1000
@KrisBee Thanks again for helping along. Yes, same issue meaning that the VM seems to suspend again. I've also switched the NIC to use VirtIO per your suggestion and rebooted the VM so we'll see how that works. With E1000 being the default NIC option, I hadn't looked at changing this item.@apwiggins When you say the "same issue" , I take it this only is after your VM has been running more than 12hrs. My small scale FreeNAS box is mostly used for backups now and on those occasions it's on all day, I've still not seen this behaviour when running a Ubuntu 18.04.3 VM ( no VNC, only ssh or serial console access) that does little more than serve a webpage on my lan for heimdall with access for a couple of other docker containers and portainer
Patrick above on this thread, who is making serious use of bhyve VMs in production, reports how illusive some bugs can be. I wonder how much development/bug fixing effort bhyve gets. Perhaps you might get some additional help/clues here: https://lists.freebsd.org/pipermail/freebsd-virtualization/
I stick to using virtio for NIC devices where possible because of various past bug report at bugs.freebsd.org
## /etc/default/grub GRUB_DEFAULT=0 #GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=2 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="" ### Change 1 - added the following string GRUB_CMDLINE_LINUX="console=ttyS0,115200n8" # Uncomment to disable graphical terminal (grub-pc only) ### Change 2 - uncomment the following line GRUB_TERMINAL=console
sudo update-grub
and reboot.sudo vi /etc/default/grub
:GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_TERMINAL='serial console' GRUB_CMDLINE_LINUX="console=hvc0 console=ttyS0,115200n8" GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
sudo update-grub
Thanks Yorick. Just needed that today!In Ubuntu 20.04 booting via EFI, these are the steps to get serial post-install. Taken from https://github.com/ynkjm/ubuntu-serial-install/.
Edit /etc/default/grub as follows withsudo vi /etc/default/grub
:
Code:GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_TERMINAL='serial console' GRUB_CMDLINE_LINUX="console=hvc0 console=ttyS0,115200n8" GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
Update grub configuration:sudo update-grub
I'm in the exact same hardware situation, except that my problems started only after I moved the VM zvol to a newly installed NVMe disk.I'm also having this issue, after upgrading to an "Intel(R) Atom(TM) CPU C3758 @ 2.20GHz (8 cores)" with 64GB of ram, so I have plenty to run some VM's.
My old board was had a "Intel Avoton C2750 Octa-Core Processor " cpu with only 16GB of ram, but running 2 VM's was more stable than now. Just to slow because they started to swap due to the lack of RAM
Upgraded board and memory for better performance, but hate it that I have to restart my VM's almost daily...
So if anyone can help it would be really appriciated.
I was thinking it's maybe some BIOS setting or so.
No NFS or SMB yet in the VM. Only installed rancher and some nodes, with nothing on it yet, except monitoring.