Re: Is it me or does FreeBSD (12.1 amd64) hang when I manually snapshot it in VSphere 6.7?
Am 2020-05-22 16:01, schrieb Scott: #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. OK, I now realized that not snapshotting the memory is way faster and doesn't crash the system. Usually, after I rollback a snapshot I reboot anyway. Because it was sometimes "funky" in the past, too. Thanks. But this should be fixed, too, at some point. Rainer ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Is it me or does FreeBSD (12.1 amd64) hang when I manually snapshot it in VSphere 6.7?
On Fri, May 22, 2020 at 12:31:29AM +0200, rai...@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: 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 > > > 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 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Is it me or does FreeBSD (12.1 amd64) hang when I manually snapshot it in VSphere 6.7?
On Fri, May 22, 2020 at 12:31:29AM +0200, rai...@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. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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: 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 This is a bit of a problem here, to say the least. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
