[Bug 271474] Possible to "lose" a tap(4) interface in a jail

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271474

--- Comment #2 from Joshua Kinard <freebsd@kumba.dev> ---
(In reply to Meyser+bugs.freebsd.org from comment #1)
> /etc/rc.d/netif is NOT invoked inside vnetjails. (novnetjail Keyword)
> so cloned interfaces are NOT destroyed during shutdown.
> 
> After changing exec.stop in /etc/jail.conf to
> 
> exec.stop = "/bin/sh /etc/rc.d/netif stop; /bin/sh /etc/rc.shutdown";
> 
> cloned interfaces are destroyed before shutdown.
> 
> Perhaps this works in your case too.
It looks like "nojailvnet" actually means "allow vnet jails", according to the
rc(8) manpage.  The wording for that rc keyword could've been chosen better,
IMHO, but in my case, I am using a VNET-enabled jail to run bhyve in.  So I
don't think this is the exact cause.

Rather than keep running this experiment on my production appliance, I dug an
older appliance out of a box and setup a clone of the production appliance's
filesystem on it to use as a toy, and tried to re-replicate the case where tap0
was getting "lost", but so far, I have no been able to find a reproducible
cause.  Stopping the jail while bhyve was running and then trying to restart it
kinda-reproduced my initial scenario where netif was unable to create tap0 on
jail start-up, but simply destroying the "dead" bhyve instance from the
host-level, then restarting the jail cleared that and tap0 could be re-created.

So I am a bit stumped how I originally triggered this fluke in a way that was
unrecoverable w/o a reboot.  That said, dropping the jail w/ bhyve running will
still create a point where the handle for tap0 is still held by bhyve and thus,
it can't be recreated next time the jail is restarted until the bhyve session
is destroyed at the host level.  So that might be a good debugging point for
someone to look into the tap(4) driver to see if there's a way to mitigate
this.

-- 
You are receiving this mail because:
You are the assignee for the bug.