This clearly has quite a bit of attention!
Is it PkgBase-friendly?
Are there any blockers other than the usual re-basing as time moves on?
If a vendor-branch import, how difficult is the maintenance burden?

From the 2024-03-12 Jail Production User Call: This looks straight-forward. (Discussion in the recording) Should save users unnecessary reboots to clean up dead jails.

In D41844#973060, @dch wrote:

thanks, builds cleanly against CURRENT on arm64 & amd64. I will try to get some testing over next week on this.

Awesome! Thank you for your efforts!

Is there any assistance, short of time, that you could use from the community to help this along?

I have tested this with root-on-ZFS using a memstick installer build from my patched /usr/src

I have testesd 14.0-BETA4 amd64 with and without this patch. dd'ing 100GB of /dev/random to a file on the SATA-booted drive works with both. This was definitely a problem with previous releases.

In D37428#936851, @editor_callfortesting.org wrote:

What CPU/motherboard/system configurations is this known to work on and people should be testing with?

Is this Review still valid, valuable, and ready to land?

What CPU/motherboard/system configurations is this known to work on and people should be testing with?

In D20967#923964, @pauamma_gundo.com wrote:

Some nits in the manual page, which can probably be fixed in a follow-up commit (with .Dd bumped) if the code still works.

In D20967#632260, @dch wrote:

This appears to have been accepted but not merged - it would be great to have it get into 13.0 if there's still time

In D1206#809386, @editor_callfortesting.org wrote:

Is this review still valid and do the concerns raised remain valid?

Hello all,

What is needed to help this review along?

FYI from 13.0R:

What is the status of this work? This feature remains desirable.

This applies cleanly to 13.0R and corrects the issue. Tested with dd(1) and fio using /dev/ada0 backed by a malloc md device.

Great work James all who have provided review!

In D26035#642819, @jhb wrote:

In D26035#641414, @editor_callfortesting.org wrote:

In testing this against 13.0-BETA1, stderr redirection does not appear to work:

bhyve -k win.cfg 2>/dev/null

This is a bit unusual. Can you show which errors you are getting on stderr that you expect to not be getting?

The boot string that the configuration file is based on works fine with stderr redirection.

In testing this against 13.0-BETA1, stderr redirection does not appear to work:

Trying to clear Phabricator messages/

When testing with fully-booted Windows Server 2019 and FreeBSD 13 guests, 10 second and 30 second waits work. (Destroy wait isn't reached)

Two people have confirmed that Windows often needs two ACPI nudges. It may be wise to take this approach.

Ignore the Dom0 reported in xl list! LOL!

Typo

royger@, Do you have any thoughts on how to elegantly check if a VM is running during start, to skip it? Will xl create generally do the right thing if a VM is already running?

I'm guessing load_rc_config $name isn't needed?

Here's a thought on VM tear-down:

royger@: I am finding that Windows sometimes needs two shutdown attempts. Should this be left to the user to verify that the shutdown was successful, or should we consider some logic to wait, destroy, etc?

(Not sure how to submit unsubmitted comments...)
Regarding "status": This relies entirely on xl(1) for status, and it just provides the facts. There is no daemon involved short of xencommons and the Xen kernel itself. I had to use xencomains_cmd because without it, the rc framework would look to see if xl was running (xl top in my case for debugging), and it would say "Hey, is this already running?" when you started domains. NetBSD opts for a "list" rather than status, and Linux does things I need to decrypt.

Removing DOCS mention, adding xencommons REQUIREment

In D28551#639106, @lwhsu wrote:

just wanted to provide some comments, not mean to block this.

Feedback from royger@: REQUIRE: XENCOMMONS (All caps?)

Let's see what royger@ says on those points. Thank you!

Correcting PREFIX and adding USE_RC_SUBR

lwhsu@,
Looking at other examples in files, is this correct?

Obsolete content

Moved to external utility in 2019

Fixed by bz@ in 2019 and re-fixed in 2021

Thank you Kyle and Ed!

Great work! Will 'config.dump' or another flag do a dry-run dump of the bhyve command to be executed? This would be very helpful. Apologies if I am overlooking it.

In D12419#417975, @yvyz_protonmail.com wrote:

In D12419#412894, @araujo wrote:

If anybody else is interested on this patch, ping me and I can share my latest changes. However I'm not interested on it anymore.

I am interested seeing this patch hit bhyve main.

This is partially obsoleted by https://reviews.freebsd.org/D19418

Thank you bz@!

I did a quick MAXCPU increase test on 12.0R based on comments by cpersiva@ but the results were neither positive nor directly related to these patches.

To use these patches, first increase VM_MAXCPU from 16 in:

I have applied these related VM_MAXCPU patches to 12.0R and rebuilt the related components.

I have split out the build option survey components and WITHOUT_DYNAMICROOT.

Ed, this builds and installs for me wth both pristine sources that include only these, and my sources with my other build option changes updated to this for dhcpclient/ping.

In D17074#364065, @emaste wrote:

This diff should address ping as well.

In D17074#364062, @emaste wrote:

Please go ahead and test if you have time, a confirmation would be good. I will send the request to re after.

That looks good to me. Please advise if you want me to test it.

I have updated the diff to remove the build option survey components and have submitted a separate diff to rgrimes for his review and review by his mentors. This is based on 12.0-ALPHA4.

From another 12.0-ALPHA4 build:

Adding the 'svnlite diff -x -U99999' full diff. Not yet broken it up.

I believe at least some of these should be addressed by fixing whatever failed rather than by excluding parts from the build; do you have a list of the errors you encountered with the various combinations? i.e., I would be interested in seeing how ping and dhclient fail under DYNAMICROOT.

For any future uploads please include full context (e.g. from git diff -U9999 or equivalent).

Replaced by the more comprehensive and tested D17040 (https://reviews.freebsd.org/D17040)

Yes, it appears syslogd can be be built with a mix of WITHOUT_INET and WITHOUT_INET_SUPPORT, plus the WITHOUT_INET6 and WITHOUT_INET6_SUPPORT

Were the tips removed by this added to adduser(8) or the Handbook?

In my testing, this appears to be based on FreeBSD 10.1, which is well supported by AHCI emulation. Supporting back to 5.0 or earlier would make this much more useful.

Consider changing it to mention of using a "memstick" .img installer in Shell mode. I find them quite useful for rescue work and the install media can even be used to boot the new installation in bhyve(8).

Have you found any time?

Several people would like to see this through. Please add a copyright and license to the work.

mat, is this something you can commit?

Ed's comments are all accurate. This document conflates many things and suggest we take a moment to address them at BSDCan or in advance. I for one think the nuts and bolts of SVN be separated out, ideally in a way that produces a document that can double as an in-base man page for snvlite(1).

Yes, this is a forklift upgrade of a ransom note of a document. Please specify the sequence of changes you would like to see.

Those Actions don't quite sound like what I want..

Those Actions are not intuitive

In D7797#162208, @avg wrote:

@editor_callfortesting.org D7612 might be of interest to you as well :-)

In D7797#162208, @avg wrote:

@editor_callfortesting.org D7612 might be of interest to you as well :-)

That's correct. And I prefer that the problem is fixed in beadm from ports.

In D7797#162091, @avg wrote:

I am strongly opposed to doing any configuration changes from a startup script.
If any tool produces a broken system configuration, then that tool should be fixed.
zfsbe will obey the ZFS properties, not change them.

Some of the issues that this addresses, as pointed out:

The original sysbench author promised an updated release but may have abandoned the project. Percona has forked it for their purposes. Other suggestions in this situation?