Date: Mon, 28 Feb 2022 18:12:00 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262113 --- Comment #4 from risner <firstname.lastname@example.org> --- As advised, I found it worked if I give it several second between the destroy and the creation of a new session. The destroy_dev_sched_cb() call is the scheduled task in the kernel. It appears to remove the /dev/vmm entry, but not yet all the kernel entries are removed by the time the create call tries to add them back. While looking at the code it felt to me this line: https://github.com/freebsd/freebsd-src/blob/22054f88914b51113f77f6eccc11353a891f9f3e/usr.sbin/bhyve/bhyverun.c#L1081 Only covered the situation of "the VM still exists" and doesn't cover "the VM is being destroy but not yet completely destroyed." In the case of it being destroyed, the code falls through to: https://github.com/freebsd/freebsd-src/blob/22054f88914b51113f77f6eccc11353a891f9f3e/usr.sbin/bhyve/bhyverun.c#L1105 with an invalid argument return value vm_open() as it's been destroy by the time this happens. Is there no way to catch the scheduled destroy and return something other than EEXIST in the create to catch this state? Addressing the points brought up (lines beginning with >> are my responses): - the docs issue that would seem to imply destroy is necessary in certain cases. >> My confusion would have been alleviated by adding a note that destroy is only needed if you have no plans to resume the vm and wish to free the wired memory. - presumably we'd like a destroy/run cycle/procedure to either a) work, or, at least b) have an improved user experience that an error every second attempt. >> Adding another state response distinct from EEXIST say perhaps ESHUTDOWN if there is scheduled destroy, the error could be less confusing by responding with "destroy in progress" or similar. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.