freebsd stable - May 2020 - Is it me or does FreeBSD (12.1 amd64) hang when I manually snapshot it in VSphere 6.7?

Hi,


subject says it all, basically.

The system becomes totally unresponsive and has to be power-cycled.

da0 at mpt0 bus 0 scbus2 target 0 lun 0
da0: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da0: Command Queueing enabled
da0: 40960MB (83886080 512 byte sectors)
da0: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>


This is a bit of a problem here, to say the least.

On Fri, May 22, 2020 at 12:31:29AM +0200, rainer at ultra-secure.de
wrote:
> subject says it all, basically.
> 
> The system becomes totally unresponsive and has to be power-cycled.

Not just you.

Specificly, the behavior I see comes about only when Snapshot with a
copy of the virtual machine's memory is done. With this box unchecked,
there are no problems.

I suspect some interaction with the kernel and the openvm-tool set.

open-vm-tools-nox11-11.0.1_3,2

I'll upgrade to the latest

open-vm-tools-nox11-11.1.0,2

and see if it does it.

No change with that version (after a reboot).

$ freebsd-version -kru
12.1-RELEASE-p5
12.1-RELEASE-p5
12.1-RELEASE-p5

vCenter server = 6.7U3g
I think I'm a little behind on the hypervisor
VMware ESXi, 6.7.0, 15160138


So, workaround I guess is to not snapshot the memory, just the disk snap.
But still, it shouldn't do that.

On Fri, May 22, 2020 at 12:31:29AM +0200, rainer at ultra-secure.de
wrote:
> Hi,
> 
> 
> subject says it all, basically.
> 
> The system becomes totally unresponsive and has to be power-cycled.
> 
> da0 at mpt0 bus 0 scbus2 target 0 lun 0
> da0: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
> da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
> da0: Command Queueing enabled
> da0: 40960MB (83886080 512 byte sectors)
> da0: quirks=0x140<RETRY_BUSY,STRICT_UNMAP>
> 
> 
> This is a bit of a problem here, to say the least.
> 
> 
#metoo:

HV: VMware ESXi, 6.7.0, 11675023
VM: # freebsd-version -kru
12.1-RELEASE-p1
12.1-RELEASE-p1
12.1-RELEASE-p1
# uname -a
FreeBSD XXX 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
# pkg info open-vm\*
open-vm-tools-nox11-11.0.1_1,2

doesn't hang but becomes *very* unresponsive over the network.  pings are 
shot.  Console is fine though.  100% idle on top across 4 cores.  And:

# openssl speed -evp aes-256-cbc
...
1024 bytes block:  542595.18k (1593774 in 3 seconds)

I never noticed that before.  I normally turn off snapshotting the RAM 
because it's so much faster and I'm happy with crash consistent
rollbacks.

Rebooting fixes the awful network behaviour.  I didn't check the disk 
subsystem.

Scott