• Do not call nvlist_destroy() on NULL.
• Update vm_pid_request() to properly set report_error depending on whether it's --get-all or --get-vm-pid option.
• bhyvectl.8: rundir: s/checkpoint socket/bhyve IPC socket/.

Fix option order in the manpage.

In D59226#1358565, @markj wrote:

Does running bhyveload ... </dev/null not provide the desired behaviour?

Re-implement using IPC.

Updated the commit metadata with all the relevant fields.

Add an UPDATING entry.

In D59108#1355951, @bnovkov wrote:

This is a good feature, but I don't think that this is the correct approach design-wise. Adding an ioctl handler to just to fetch a VM's PID is overkill IMO, new ioctl commands should only be added when there's no other way to obtain the needed information (e.g., fetching memsegs and other metadata that is stored in the vmm module).

I strongly suggest that you implement this functionality using bhyve's IPC facilities. These were only reserved for the snapshot subsystem up until very recently, but I had to split these out into a separate subsystem as a part of my hotplugging work.
This should make the implementation way simpler since you just need to register an IPC handler instead of adding a new ioctl.
I just committed the refactor so you can build on top of it.

In D59080#1355723, @chuck wrote:

Thanks for finding this and fixing it.

In D59080#1354973, @markj wrote:

I'm not very familiar with nvme, but I presume this might cause problems in existing VM images that embed this identifer somewhere?

Re-implement monitoring using a pipe.

In D58788#1348937, @bnovkov wrote:

In D58788#1348916, @markj wrote:

Thanks, I've run into this problem too.

Rather than forwarding signals, why not have a pipe shared between the two processes? The child process can use it to detect when the parent goes away, and exit automatically. That should be simpler and will work for all cases where the parent exits (assertion failure, SIGKILL, etc.).

+1 for this approach, it's more robust than forwarding signals. I was planning to implement this pipe-based fix soon, but if you have the time and will to do so please go for it!

manpages ping

In D58419#1340678, @chuck wrote:

I like the approach of defining the options in each module (e.g., machdep), but it would be interesting to see what this approach looks like for one of the storage devices (e.g., NVMe) which have both their own options as well as the common blockif options.

Support module-based options sets.

@bcr @ziaee could you possibly take a look?

Address comments (formatting).

bhyvectl.8: add '--rundir' to synopsis

Address review comments about manpages.

Address review comments.

In D57372#1315046, @markj wrote:

In D57372#1314941, @ivy wrote:

if this is specific to snapshots, perhaps a new bhyve argument could be used to specify the socket directory it uses for that.

Yes, that seems better.

In D57372#1314712, @markj wrote:

In D57372#1314709, @novel wrote:

In D57372#1314650, @markj wrote:

in this case

You might further specify which case this is?

In case of running bhyve as a non-root user.

I run bhyve as a non-root user many times every day, and I don't see this.

Specifically:

$ sudo -u bhyve -g vmm \
       bhyve -M -c 2 -m 4096 -u -H -P -s 0:0,hostbridge -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
                                                               -s 2:0,xhci,tablet -s 1:0,lpc \
                                                               -s 3:0,ahci,cd:/data/isos/alpine-standard-3.23.4-x86_64.iso -s 6:0,fbuf,tcp=127.0.0.1:5901 \
                                                               alpine
fbuf frame buffer base: 0x327758a00000 [sz 33554432]
Failed to bind socket "/var/run/bhyve/alpine": Permission denied

bhyve: Failed to start checkpoint thread
$

Ah, this is with snapshot support enabled I guess?

In D57372#1314650, @markj wrote:

in this case

You might further specify which case this is?